On 16 Jul 2012, at 09:22, Skybuck Flying wrote: > -----Original Message----- From: Jonas Maebe > Sent: Sunday, July 15, 2012 15:49 > To: FPC developers' list > Subject: Re: [fpc-devel] Class field reordering > > >> On 14 Jul 2012, at 14:16, Skybuck Flying wrote: >> >>> I don't think this is a good idea. >>> >>> For example while debugging and looking at the memory in raw this would >>> lead to confusion. >> >> By knowing the order of the fields, you still don't know their exact >> offsets. If you want to know their address, print @classinstance.fieldname > > Yes but I do know the order of the fields which does help make some sense of > it. With your suggested optimizations it would become much more > confusing/mixed/shuffled. > > I also find it slightly strange how there is now an even bigger disconnect > between records and classes.
The whole point of classes is to offer abstraction. Again: if you don't want abstraction, don't use data structures that offer an abstraction. > I also wonder how much of an optimization it actually is ? Maybe 0.000001% > more performance ? 1) as mentioned in the original mail, the current transformation is implemented for saving memory, not for improving performance 2) if it was done for performance reasons, some people already got up to 34% extra performance by doing exactly that: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.4009 (download the cached version of the paper, the original link no longer works) > I rarely inspect the binary equivalent of a class instance, so your > supposedly optimization is probably not a big deal, for records that would be > a different matter since these are used in all kinds of api's and > input/output situations. As mentioned in the original mail, the transformation would only be applied to classes. >>> It's already bad that Delphi adds invisible fields to classes so they >>> cannot be simply dumped to disk... (virtual method table pointers ?) this >>> would make it even worse. >> >> If you want to program at an assembler level of abstraction, don't use high >> level language features. > > I see no reason why a high level language could not be used to produce binary > instructions and or files/data. It can be used for that, as long as you don't use high level abstractions. The whole point of abstractions to get rid of any guarantees a far as implementation is concerned, in order to increase portability, programmer productivity and compiler optimization opportunities. Jonas_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
