Hi Sven,

I saw the new commits related to Management Operators (I mean new flags riifNonTrivialChild and riifParentHasNonTrivialChild) and I wonder what next.

When I was developing management operators (and FastRTTI related to speed up things) I had in mind extensive expansion for management types in many directions (nullable types, smart pointers and so one, FastRTTI is also related to all managed types not only to management operators) and optimizations to speed up things (in the final, generated code can be faster even few times than current code, here I mean code with standard managed types without any management operators).

The FastRTTI covers the needs of the optimization for constructors but also moves things much forward (it depends on use case: from my tests is never slower but always faster, for some cases even few times).

For example the new flags (riifNonTrivialChild and riifParentHasNonTrivialChild) works good only when none of record with "Initialize operator" is used as field, also worth to note that new solution will be much slower in the future than FastRTTI when users will decide to use more types backed by management operators (and the topic will back again...).

Current flags are temporary solution or final thing? I have few things to say

A. we have ready to use better/faster solution than riifNonTrivialChild riifParentHasNonTrivialChild
B. current solution probably means also waste of memory for TRecordInfoInitFlags when in the future someone decide to introduce other optimizations related to RTTI and managed types (similar to FastRTTI) C. also is possible to use less invasive version of FastRTTI (for example can be used part related to Initialize operator only (this part is already exposed outside FastRTTI structures and is generated always even when fast RTTI is off) and the way for full FastRTTI will be opened without wast of space for new flags...
D. Do we really want to use temporary solution? I think no - we should looks forward.
E. FastRTTI is just beginning and can be expanded to more optimizations F. if for some reasons you want to keep current solution (anyway IMO very unwelcome for future things) may be worth to rename TRecordInfoInitFlags because can be also used for other purposes not related to initialization only. For example all flags defined for FastRTTI can be moved into this flag... Anyway TRecordInfoInitFlags will be still less efficient than FastRTTI for 8 and 16 bit platforms...

We don't really know when your FastRTTI changes are going to be integrated or if they are going to be integrated at all; the performance of classes that don't have fields that use an Initialize operator needed to be restored sooner rather than later. This is especially important as on Core we've recently started talking about branching of 3.2 and even though I've implemented my Flags based solution before that discussion was started it's definitely an important point.
Also your FastRTTI approach and the Flags can coexist without problems (and even complement each other) from what I've read in the thread where you introduced your idea. That said I seriously doubt that the flags are less efficient than FastRTTI for 8 and 16 bit platforms (where we had said that FastRTTI isn't used by default) or even the 32 or 64 bit ones, because with the flags no initialization aside from FillChar() is executed at all for classes that contain managed types, but no types with an initialize operator (while with the FastRTTI disabled the record initialization would still be executed).

Regards,
Sven

2018-06-21 22:09 GMT+02:00 Sven Barth via fpc-devel <

Sven you are wrong, flags for this case are less efficient for 8 and 16 bit platforms and not only for this platforms. This is also true even for other platforms even when FastRTTI is off. This is because

RecordRTTI(Instance,Temp,@int_initialize);

is never called even for disabled FastRTTI. Instead of this in the place of current RecordRTTI call is used

https://github.com/maciej-izak/freepascal/blob/fastrtti/rtl/inc/objpas.inc#L392-L396

here is used simple table of all initialize operators to call. This table is always generated as special part of INIT RTTI (independent from other FastRTTI stuff) for maximal performance of this critical RTL part. The pointer to table of all initialize operators is in the place of current new field "Flags: TRecordInfoInitFlags;". No need for redundant call to RecordRTTI which dose many redundant things like initialization for already initialized managed fields and many potential calls to next RecordRTTI...

Coexistence of both has no sense - information stored in Flags will be useless, this info is for sure not complement :( .

I can propose to adjust all needed things in FastRTTI patch before 3.2 branching, I think this will be good for all (FPC will be much faster in many areas than Delphi!) . I have just few minor things to finish (one day of work?).

The patch was tested for all platforms: 8bit, 16bit, 32, 64 also for big endian without single regression. Additionally patch was tested with all available very strict mORMot tests, so I think FastRTTI is really stable.

2018-06-21 22:50 GMT+02:00 Maciej Izak :

Coexistence of both has no sense - information stored in Flags will be useless, this info is for sure not complement :( .

I see 4 options:

1. integration of FastRTTI
2. limited integration, only part of "FastRTTI" branch (only table with initialization operators and related compiler and RTL part)
3. moving "Flags: TRecordInfoInitFlags;" into private section of record in TypInfo module, it can be removed in the future (if needed) without breaking backward compatibility for users code
4. all will stay as-is (the worst scenario)

The option 2 seems optimal (no redundant/useless actions/calls in constructors).

2018-06-22 21:08 GMT+02:00 Maciej Izak :

Ping? Would be good to know what you decide.

Sorry that it took me so long, but I wanted to reread your proposed FastRTTI changes before deciding and I only found the time this evening.

I'm currently indeed leaning towards option 2.
If you want to prepare this you can of course do it in a way that allows to easily add in your other FastRTTI changes at a later date (though those are still a bit up for debate (lessthe principal idea, more the concrete implementation)).

Regards,
Sven

2018-06-28 22:10 GMT+02:00 Sven Barth via fpc-devel <

This is good info.

This is good info too. So we can keep all gathered information about "managed things" in compiler without producing final FastRTTI (only mentioned table of initialization operators - which is special).

I agree that implementation in details may change and is for debate.

In early July I will prepare code base for both : FPC trunk and NewPascal, and I will continue development of FastRTTI:

- integration with NewPascal for current layout of FastRTTI, which can be changed/adjusted at any time.

also some new directions (also partially related to FastRTTI):

- inline management operators
- inline initialization for managed fields, local managed variables (probably this can provide a lot of additional performance on user request).

This shows that NewPascal as "bleeding edge technology" (anyway tested with all available tests) is a good idea. :)

I will for sure adjust FastRTTI, when I will get any feedback from you (or any other core developer). It is very good that will be possible to keep single code base in this matter.