[fpc-devel] Class field reordering

2012-07-13 Thread Jonas Maebe


Hi,

I've implemented an optimization that reorders the instance fields of  
Delphi-style classes (and only of Delphi-style classes) to minimise  
memory gaps caused by alignment differences and odd sizes. The effect  
is the same as when you would change the order of the fields in the  
source code to achieve this effect.


In general, I think this should be safe since unlike records and  
TP-style objects, a Delphi class is normally never blockwritten to  
disk or so. There is a switch to disable this transformation, but I'm  
wondering whether anyone sees a problem with enabling it by default  
when -O2 or higher is used.


It works fine with at least the compiler and Lazarus without any ill  
effects, saving a small amount of memory for both (about 2.5MB on 87MB  
for the Darwin/x86-64 compiler compiling itslf, and 2.5MB on 62.7MB  
for a Carbon/i386 Lazarus right after startup and loading some source  
files).



Jonas

PS: a similar reordering could be performed for local variables,  
although the implementation would be quite different. Additionally,  
different kinds of reordering, e.g. targeting cache improvements by  
putting fields/local variables often used together next to each other,  
could also be implemented in the future.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


[fpc-devel] Class field reordering

2012-07-13 Thread Jonas Maebe

Hi,

I've implemented an optimization that reorders the instance fields of  
Delphi-style classes (and only of Delphi-style classes) to minimise  
memory gaps caused by alignment differences and odd sizes. The effect  
is the same as when you would change the order of the fields in the  
source code to achieve this effect.


In general, I think this should be safe since unlike records and  
TP-style objects, a Delphi class is normally never blockwritten to  
disk or so. There is a switch to disable this transformation, but I'm  
wondering whether anyone sees a problem with enabling it by default  
when -O2 or higher is used.


It works fine with at least the compiler and Lazarus without any ill  
effects, saving a small amount of memory for both (about 2.5MB on 87MB  
for the Darwin/x86-64 compiler compiling itslf, and 2.5MB on 62.7MB  
for a Carbon/i386 Lazarus right after startup and loading some source  
files).



Jonas

PS: a similar reordering could be performed for local variables,  
although the implementation would be quite different. Additionally,  
different kinds of reordering, e.g. targeting cache improvements by  
putting fields/local variables often used together next to each other,  
could also be implemented in the future.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Class field reordering

2012-07-13 Thread Craig Peterson


On Jul 13, 2012, at 6:44 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:

 
 Hi,
 
 I've implemented an optimization that reorders the instance fields of 
 Delphi-style classes (and only of Delphi-style classes) to minimise memory 
 gaps caused by alignment differences and odd sizes. The effect is the same as 
 when you would change the order of the fields in the source code to achieve 
 this effect.
 
 In general, I think this should be safe since unlike records and TP-style 
 objects, a Delphi class is normally never blockwritten to disk or so. There 
 is a switch to disable this transformation, but I'm wondering whether anyone 
 sees a problem with enabling it by default when -O2 or higher is used.
 
 It works fine with at least the compiler and Lazarus without any ill effects, 
 saving a small amount of memory for both (about 2.5MB on 87MB for the 
 Darwin/x86-64 compiler compiling itslf, and 2.5MB on 62.7MB for a Carbon/i386 
 Lazarus right after startup and loading some source files).
 
 
 Jonas
 
 PS: a similar reordering could be performed for local variables, although the 
 implementation would be quite different. Additionally, different kinds of 
 reordering, e.g. targeting cache improvements by putting fields/local 
 variables often used together next to each other, could also be implemented 
 in the future.
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-devel

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Class field reordering

2012-07-13 Thread Martin Schreiber
On Saturday 14 July 2012 01:44:39 Jonas Maebe wrote:
 Hi,

 I've implemented an optimization that reorders the instance fields of
 Delphi-style classes (and only of Delphi-style classes) to minimise
 memory gaps caused by alignment differences and odd sizes. The effect
 is the same as when you would change the order of the fields in the
 source code to achieve this effect.

I sometimes need cracker classes in MSEide and MSEgui to fix bugs and make 
extensinsions for FCL classes in order to access private fields (examples 
TDataset, TParam, TField, TFiler, TReader, TWriter, TComponent).
Is it guaranteed that the local definitions have the same layout as the 
definition in the FCL unit?

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Class field reordering

2012-07-13 Thread Martin Schreiber
On Saturday 14 July 2012 07:50:58 Martin Schreiber wrote:
 On Saturday 14 July 2012 01:44:39 Jonas Maebe wrote:
  Hi,
 
  I've implemented an optimization that reorders the instance fields of
  Delphi-style classes (and only of Delphi-style classes) to minimise
  memory gaps caused by alignment differences and odd sizes. The effect
  is the same as when you would change the order of the fields in the
  source code to achieve this effect.

 I sometimes need cracker classes in MSEide and MSEgui to fix bugs and
 make extensinsions for FCL classes in order to access private fields
 (examples TDataset, TParam, TField, TFiler, TReader, TWriter, TComponent).
 Is it guaranteed that the local definitions have the same layout as the
 definition in the FCL unit?

Hmm, up to now I listed in the cracker classes fields up to the last private 
field I need to access so the cracker classes would not brake by changing or 
adding successive fields in the original classes. I assume now it is 
necessary to always list all fields of the original class.

Martin


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel