[fpc-devel] Attn Sven: New flags related to management operators

[Maciej Izak]

2018-06-21 22:09 GMT+02:00 Sven Barth via fpc-devel <
fpc-devel at lists.freepascal.org>:
>
> 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).
>

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, at 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.

-- 
Best regards,
Maciej Izak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180621/06cbe629/attachment.html>