Am 20.06.2018 um 23:41 schrieb Maciej Izak:
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 futurethan 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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
