<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2018-06-21 22:09 GMT+02:00 Sven Barth via fpc-devel <span dir="ltr"><<a href="mailto:fpc-devel@lists.freepascal.org" target="_blank">fpc-devel@lists.freepascal.org</a>></span>:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    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.<br>
    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).<br></div></blockquote><div><br></div><div>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 </div><div><br></div><div>RecordRTTI(Instance,Temp,@int_initialize);<br></div><div><br></div><div>is never called even for disabled FastRTTI. Instead of this in the place of current 

<span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">RecordRTTI call</span> is used </div><div><br></div><div><a href="https://github.com/maciej-izak/freepascal/blob/fastrtti/rtl/inc/objpas.inc#L392-L396">https://github.com/maciej-izak/freepascal/blob/fastrtti/rtl/inc/objpas.inc#L392-L396</a><br></div><div><br></div><div>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 <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">RecordRTTI which dose many redundant things like initialization for already initialized managed fields and many potential calls to next RecordRTTI...</span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Coexistence of both has no sense - information stored in Flags will be useless, this info is for sure not complement :( .</span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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?).</span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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.</span></div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Best regards,<br>Maciej Izak</div></div></div>
</div></div>