[fpc-devel] Class field reordering

[Skybuck Flying]

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