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

Reply via email to