Hallo,

i made a patch for faster management operators:
https://gitlab.com/benibela/fpc-source/-/commit/1aa0866112c97dd0c7ed7f3a4b1c7ab6420cb942

And it has been working fine on fixes3_2, but when I tried to apply it on main, I get an error message:

views.inc(4318,17) Error: Wrong number of parameters specified for call
to "$copy"
video.inc(180,35) Error: Found declaration: operator copy(constref
TEnhancedVideoCell;var TEnhancedVideoCell); Static;

I have been creating two paranodes for the call like that:

           if is_rtti_managed_type(left.resultdef) and is_record(left.resultdef)
               and (mop_copy in
trecordsymtable(left.resultdef.getsymtable(gs_record)).managementoperators) then
             begin
               hsym :=
tprocsym(left.resultdef.getsymtable(gs_record).Find('copy'));                hp := ccallparanode.create(left, ccallparanode.create(right, nil));
               result := ccallnode.create(hp,hsym,hsym.owner,nil,[],nil);

should it be done differently?

Viele Grüße,

Benito

Nice work, I have no answer for you though. :)

What is the performance improvement here and why was it done the old way?

Another question I had about them is why they can't be inlined. Does anyone have the answer for that? Not being able to be inlined is the biggest performance problem I suspect, followed by the copy operator which gets called redundantly on assignment to temporary memory.

Regards,
Ryan Joseph

Hi,

main fails to cycle compile rtl-console/fv-package due to a TEnhancedVideoCell record.
fixes does not have a TEnhancedVideoCell record, so it cannot fail there.

But if I copy TEnhancedVideoCell into a new project file, I can compile it with the patched fixes, too

What is the performance improvement here

I did not benchmark it.

I tested my test cases after dozen of unrelated changes. I started with COM interfaces for reference counting. There the run time was like 80 seconds. Then I changed it to managed records. Now it is around 30 seconds.

and why was it done the old way?

what old way?

Another question I had about them is why they can't be inlined.

with my patch, "copy" can be inlined!

initialize and finalize some times, too.

There are two places that call them. compiler/nld.pas and compiler/ngenutil.pas where it creates the call nodes. There my patch turns them into ordinary function calls, which can be inlined like any other function call.
Then there is compiler/hlcgobj.pas, which calls initialize/finalize for local or temporary variables. That appears to happen after the inlining is done.  Perhaps it needs to do the inlining first to know which variables are there, and afterwards it could not change them anymore.

Bye,
Benito

On Jul 23, 2023, at 7:13 AM, Benito van der Zander via fpc-devel wrote: with my patch, "copy" can be inlined! initialize and finalize some times, too.

Amazing!

There are two places that call them. compiler/nld.pas and compiler/ngenutil.pas where it creates the call nodes. There my patch turns them into ordinary function calls, which can be inlined like any other function call.

This is the "old way" you describe. Why did they do it like this instead of normal function calls which could be inlined? I suspect one of the compiler devs needs to explain this because there may be a reason.

Then there is compiler/hlcgobj.pas, which calls initialize/finalize for local or temporary variables. That appears to happen after the inlining is done. Perhaps it needs to do the inlining first to know which variables are there, and afterwards it could not change them anymore.

So the inlining caused extra init/finalize calls? That's not good for sure. There's already a problem with an extra copy operator being called on temporary memory which can make or break the feature entirely depending on your usage.

Regards,
Ryan Joseph

Hi

i have found the problem

views.inc(4318,17) Error: Wrong number of parameters specified for call to "$copy"

that is not what it says

It has nothing to do with the parameters. FPC generates this message if no matching callable function is not found for any reason

In this case because "copy" was not public in the record. I can set a flag [cnf_ignore_visibility] in the compiler

Bye,
Benito