Call to subroutine, marked as inline is not inline

[andersonscinfo]

Hi, I have code using variables of the variant type, and it keeps giving an annoying message from the compiler, in fact this should be something that I should pay more attention to, I would like to know if I am doing the right thing by ignoring it, or if I should change this code to make it more explicit, and so these messages stop appearing.

Code: Pascal  [Select][+][-]

1. function TConfigLocal.Get(const APath: String; const APadrao: Variant
2.   ): IJSONValue;
3. Var
4.   VStr: TArrayOfString;
5. begin
6.   VStr:=APath.Split('.');
7.   Result:=TJSONString.New(
8.     Get(VStr[0], VStr[1], APadrao)
9.   );
10. end;

the image is attached

[MarkMLl]

Ignore it, or tell the IDE to ignore it.

In most cases that means that the abstract structure (tree) that the compiler uses to represent a function exceeds the hardcoded limit (number of nodes) that the FPC developers think is appropriate: my recollection is that this is around 40 and you can get there either by having too many lines, excessively complex expressions, or lots of fancy address etc. handling.

Frankly, and this is my personal (hence uninformed :-) position, is that the inline keyword should be obeyed unconditionally since from the POV of the language it appears in the same context as a memory model or forward directive: if the compiler really can't honour it then that should be an error rather than a warning. However I'm not a core developer, and I'm sure that if I were they'd browbeat me until I conformed to the majority opinion :-)

MarkMLl

[Thaddy]

Yes, indeed, and it is a note, not a warning.
Especially using variants, the code becomes too complex to inline.
Are you sure you need a variant here?
Because that will slow down your code anyway!, inlined or not.
Variants are guaranteed to provide slow code.
For - much - faster code, just provide overloaded functions for the types you really need and those will usually be inlined.

[marcov]

Both Split and .new() probably allocate memory, so than it is already beyond the magnitude where inline is useful. Also there is a implicit try finally because of the managed types.

For inline to have a decent effect, the function overhead (parameter preparation, actual call, prologue and epilogue) need to be relatively large to what the function does, and this function doesn't look like it.

[Thaddy]

I just tested: when I change variant to string it is inlined....

[andersonscinfo]

Thank you everyone, at the end I will make some adjustments and remove the variant for an "IJsonValue" type, again thank you very much...

Att.

[marcov]

I just tested: when I change variant to string it is inlined....

If it allows it, doesn't mean it is sane. It is just an upper limit.

[Thaddy]

No, Marco, it is the variant that prevents ilining it.

[PascalDragon]

No, Marco, it is the variant that prevents ilining it.

Yes, it prevents it, but marcov was talking about whether inline made sense there.

Hi, I have code using variables of the variant type, and it keeps giving an annoying message from the compiler, in fact this should be something that I should pay more attention to, I would like to know if I am doing the right thing by ignoring it, or if I should change this code to make it more explicit, and so these messages stop appearing.

You can ignore these notes, cause aside from not using variants you can't do anything against the hint, because it's triggered by the assignment itself.

In FPC main these kind of assignment operators can be successfully inlined, because FPC main is able to do cross-unit access for implementation-variables for inlining, in this case the VariantManager variable inside the System unit.