[fpc-devel] Class field reordering
skybuck2000 at hotmail.com
Mon Jul 16 09:22:39 CEST 2012
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
I also find it slightly strange how there is now an even bigger disconnect
between records and classes.
I also wonder how much of an optimization it actually is ? Maybe 0.000001%
more performance ?
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
I still find your suggested optimization weird though. CPU cache lines as
far as I know are 64 bytes or so... Let's assume a class with 10 fields each
4 bytes long, that's 40 bytes.
How would re-ordering fields lead to faster performance ? I don't really see
> 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.
More information about the fpc-devel