<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Am 20.06.2018 um 23:41 schrieb Maciej
Izak:<br>
</div>
<blockquote type="cite"
cite="mid:CAFTppY75tKant=G6mJ5EDHCaE+=kXTvddzCyoNL6_G9+rTgHEw@mail.gmail.com">
<div dir="ltr">Hi Sven,
<div><br>
</div>
<div>I saw the new commits related to Management Operators (I
mean new flags riifNonTrivialChild and
riifParentHasNonTrivialChild) and I wonder what next.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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). </div>
<div><br>
</div>
<div>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 <span
style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">in
the future<span> </span></span>than FastRTTI when users will
decide to use more types backed by management operators (and
the topic will back again...). </div>
<div><br>
</div>
<div>Current flags are temporary solution or final thing? I have
few things to say</div>
<div><br>
</div>
<div>A. we have ready to use better/faster solution
than riifNonTrivialChild riifParentHasNonTrivialChild<br>
</div>
<div>B. current solution probably means also waste of memory for
<span
style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">TRecordInfoInitFlags </span>when
in the future someone decide to introduce other optimizations
related to RTTI and managed types (similar to FastRTTI)</div>
<div>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...</div>
<div>D. Do we really want to use temporary solution? I think no
-
<span
style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">we
should looks forward.</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">E.
FastRTTI is just beginning and can be expanded to more
optimizations</span></div>
<div>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...<br>
</div>
</div>
</blockquote>
<br>
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>
<br>
Regards,<br>
Sven<br>
</body>
</html>