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

[Sven Barth]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180621/8bad756d/attachment.html>