-----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.
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
input/output situations.
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
that...
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.
Bye,
Skybuck.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel