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

Maciej Izak hnb.code at gmail.com
Wed Jun 20 23:41:52 CEST 2018


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

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


More information about the fpc-devel mailing list