On 14/07/2012 20:46, Jonas Maebe wrote:
That may actually lead to quite some troubles: if someone recompiles the RTL without
optimizations, then your class crackers also have to change that setting. And there's no
way to detect how the RTL (or in general: units containing classes you are
"crac
> I also wonder how much of an optimization it actually is ? Maybe
> 0.01%
> more performance ?
"
1) as mentioned in the original mail, the current transformation is
implemented for saving memory, not for improving performance
"
This wasn't clear, it only mentions gaps. What kind of gaps ?
On Thursday 19 July 2012 05:13:01 Luiz Americo Pereira Camara wrote:
> I also have somethings in fpc rtl/fcl that also don't like or changing
> would simplify my work. But if we start to change base classes at each
> developer request we may end with a mess.
> Just to be clear, i'm not against all
Em 18/7/2012 03:19, Martin Schreiber escreveu:
Thank you. There are more items in the db.pas list...
But I think first we should concentrate on classes.pas because I really don't
want to fork it. Forking db.pas is less problematic and I probably prefer it
in place of an endless discussion and in
Am 18.07.2012 10:08 schrieb "Martin Schreiber" :
>
> On Wednesday 18 July 2012 09:33:09 michael.vancann...@wisa.be wrote:
>
> > I think you are missing an important point:
> >
> > You want some radical changes, so I expect you to be the one giving the
> > reasons/motivations for a change. I want to
On Wednesday 18 July 2012 10:50:36 michael.vancann...@wisa.be wrote:
> >> If you don't give a detailed explanation why you need to manipulate
> >> all these private fields outside of the proper methods, then I cannot
> >> help you find solutions for the problems you experience, so please:
> >> ela
On Wed, 18 Jul 2012, Martin Schreiber wrote:
On Wednesday 18 July 2012 09:33:09 michael.vancann...@wisa.be wrote:
I think you are missing an important point:
You want some radical changes, so I expect you to be the one giving the
reasons/motivations for a change. I want to help find solutio
On Wednesday 18 July 2012 09:33:09 michael.vancann...@wisa.be wrote:
> I think you are missing an important point:
>
> You want some radical changes, so I expect you to be the one giving the
> reasons/motivations for a change. I want to help find solutions, but not
> at the price of destroying wha
On Wednesday 18 July 2012 09:43:16 michael.vancann...@wisa.be wrote:
> On Wed, 18 Jul 2012, Martin Schreiber wrote:
> > On Wednesday 18 July 2012 08:19:02 Martin Schreiber wrote:
> >> Used in order TParams create tmseparam items instead of TParam:
> >>
> >> TCollection:
> >> - FItemClass
> >
> > Pr
On Wed, 18 Jul 2012, Martin Schreiber wrote:
On Wednesday 18 July 2012 08:19:02 Martin Schreiber wrote:
Used in order TParams create tmseparam items instead of TParam:
TCollection:
- FItemClass
Probably can be solved in a forked db.pas
Or by 2 other solutions:
* having a global variable
On Wed, 18 Jul 2012, Martin Schreiber wrote:
On Tuesday 17 July 2012 09:40:36 michael.vancann...@wisa.be wrote:
Maybe, but what about performance? Another complication is the
"updatebuffer" with the "oldvalues".
Thinking about it:
I would allocate the buffer as is, with for all string fiel
On Wednesday 18 July 2012 08:19:02 Martin Schreiber wrote:
> Used in order TParams create tmseparam items instead of TParam:
>
> TCollection:
> - FItemClass
>
Probably can be solved in a forked db.pas
Martin
___
fpc-devel maillist - fpc-devel@lists.fre
On Tuesday 17 July 2012 09:40:36 michael.vancann...@wisa.be wrote:
> > Maybe, but what about performance? Another complication is the
> > "updatebuffer" with the "oldvalues".
>
> Thinking about it:
>
> I would allocate the buffer as is, with for all string fields an
> integer-sized slot in the buff
Hi,
On Tue, 2012-07-17 at 08:22 +0200, Skybuck Flying wrote:
> > I also wonder how much of an optimization it actually is ? Maybe 0.01%
> > more performance ?
>
> "
> 1) as mentioned in the original mail, the current transformation is
> implemented for saving memory, not for improving perfo
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 th
On Tue, 17 Jul 2012, Martin Schreiber wrote:
On Monday 16 July 2012 17:25:58 michael.vancann...@wisa.be wrote:
On Mon, 16 Jul 2012, Martin Schreiber wrote:
On Monday 16 July 2012 16:50:06 michael.vancann...@wisa.be wrote:
Well, from your code adding the following to the protected section:
On Monday 16 July 2012 17:25:58 michael.vancann...@wisa.be wrote:
> On Mon, 16 Jul 2012, Martin Schreiber wrote:
> > On Monday 16 July 2012 16:50:06 michael.vancann...@wisa.be wrote:
> >> Well, from your code adding the following to the protected section:
> >>
> >>Property ValueBuffer : Pointer
On Mon, 16 Jul 2012, Martin Schreiber wrote:
On Monday 16 July 2012 16:50:06 michael.vancann...@wisa.be wrote:
Well, from your code adding the following to the protected section:
Property ValueBuffer : Pointer Read FValueBuffer;
Property Validating : Boolean Read FValidating ;
Should
On Monday 16 July 2012 16:49:24 Mattias Gaertner wrote:
>
> AFAIK inheriting forms with nested frame with nested frame works in
> Lazarus. Some years ago I fixed a bug which only appeared at 5
> level depth.
> TReader/Writer does not know about forms/frames/datamodules, so I guess
> it should work
On Monday 16 July 2012 16:50:06 michael.vancann...@wisa.be wrote:
>
> Well, from your code adding the following to the protected section:
>
>Property ValueBuffer : Pointer Read FValueBuffer;
>Property Validating : Boolean Read FValidating ;
>
> Should be enough to remove the need for the TF
On Mon, 16 Jul 2012, Martin Schreiber wrote:
On Monday 16 July 2012 09:35:16 michael.vancann...@wisa.be wrote:
The DB components mainly because MSEgui stores string fields as
UnicodeString in datasets and because of the direct data access by index
without scrolling.
So you take away the c
On Mon, 16 Jul 2012 16:18:49 +0200
Martin Schreiber wrote:
> On Monday 16 July 2012 14:08:23 Mattias Gaertner wrote:
> > On Mon, 16 Jul 2012 09:35:16 +0200 (CEST)
> >
> > michael.vancann...@wisa.be wrote:
> > >[...]
> > >
> > > > TComponent, TWriter, TReader for example because in
> > > > MSEide+
On Monday 16 July 2012 09:35:16 michael.vancann...@wisa.be wrote:
>
> > The DB components mainly because MSEgui stores string fields as
> > UnicodeString in datasets and because of the direct data access by index
> > without scrolling.
>
> So you take away the concept of cursor. That is a radical c
On Monday 16 July 2012 14:08:23 Mattias Gaertner wrote:
> On Mon, 16 Jul 2012 09:35:16 +0200 (CEST)
>
> michael.vancann...@wisa.be wrote:
> >[...]
> >
> > > TComponent, TWriter, TReader for example because in
> > > MSEide+MSEgui one can place additional components in an inserted tframe
> > > and co
On 16.07.12 09:22, Skybuck Flying wrote:
> I also wonder how much of an optimization it actually is ? Maybe
> 0.01% more performance ?
Cache related optimizations are VERY hard to measure and depend on
overall context and used architecture. But as the L1-cache is one of the
most performance c
On Mon, 16 Jul 2012, Mattias Gaertner wrote:
On Mon, 16 Jul 2012 09:35:16 +0200 (CEST)
michael.vancann...@wisa.be wrote:
[...]
TComponent, TWriter, TReader for example because in
MSEide+MSEgui one can place additional components in an inserted tframe and
combination of inherited frames and
On Mon, 16 Jul 2012 09:35:16 +0200 (CEST)
michael.vancann...@wisa.be wrote:
>[...]
> > TComponent, TWriter, TReader for example because in
> > MSEide+MSEgui one can place additional components in an inserted tframe and
> > combination of inherited frames and inherited forms need special handling.
On 16 Jul 2012, at 13:14, Sven Barth wrote:
> does this optimization
> also apply on systems that require proper alignment for memory accesses?
Well, yes, otherwise the "optimization" would simply consist of removing all
alignment padding and there would be no need to reorder the fields.
Jona
On 16 Jul 2012, at 09:22, Skybuck Flying wrote:
> -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:
&g
Am 14.07.2012 01:45 schrieb "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 cha
-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
On Sun, 15 Jul 2012, Martin Schreiber wrote:
On Sunday 15 July 2012 19:21:58 Michael Van Canneyt wrote:
On Sun, 15 Jul 2012, Martin Schreiber wrote:
Currently I need access to the following private FCL class fields because
of MSEide+MSEgui extensions:
I have looked at your list. (I sent my
Graeme Geldenhuys schrieb:
On 15 July 2012 19:04, Michael Van Canneyt wrote:
Usually these things are private for a reason. But maybe there are better
reasons for doing it different, of course then I'd like to hear them first
:)
Yes, and I just wanted to point out that I some time ago I showe
On 15 July 2012 19:04, Michael Van Canneyt wrote:
> Usually these things are private for a reason. But maybe there are better
> reasons for doing it different, of course then I'd like to hear them first
> :)
Yes, and I just wanted to point out that I some time ago I showed a
case where I needed t
On Sunday 15 July 2012 19:21:58 Michael Van Canneyt wrote:
> On Sun, 15 Jul 2012, Martin Schreiber wrote:
> > Currently I need access to the following private FCL class fields because
> > of MSEide+MSEgui extensions:
>
> I have looked at your list. (I sent my previous mail about this without
> havi
On Sun, 15 Jul 2012, Graeme Geldenhuys wrote:
Hi,
On 15 July 2012 18:21, Michael Van Canneyt wrote:
For example:
TParam.FBound
Is directly accessible through TParam.Bound, so why on earth would you need
to have it protected ??
Anyway, I'm not saying I agree with his whole list... as your
Hi,
On 15 July 2012 18:21, Michael Van Canneyt wrote:
> For example:
> TParam.FBound
> Is directly accessible through TParam.Bound, so why on earth would you need
> to have it protected ??
I haven't worked through his list myself, but I had a quick look at
one property I had issues with ages ag
On Sun, 15 Jul 2012, Martin Schreiber wrote:
Currently I need access to the following private FCL class fields because of
MSEide+MSEgui extensions:
I have looked at your list. (I sent my previous mail about this without having
seen the list)
At first sight, I see no reason to make any of
On Sat, 14 Jul 2012, Martin Schreiber wrote:
On Saturday 14 July 2012 14:26:32 Michael Van Canneyt wrote:
If would you want to use that optimization, then yes. "Working around"
the type system of the language is however generally asking for trouble,
regardless of what reason you do it for.
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
ke it even worse.
Bye,
Skybuck.
-Original Message-
From: Jonas Maebe
Sent: Saturday, July 14, 2012 1:44
To: fpc-devel@lists.freepascal.org
Subject: [fpc-devel] Class field reordering
Hi,
I've implemented an optimization that reorders the instance fields of
Delphi-style class
On 15.07.2012 08:58, Martin Schreiber wrote:
I report all FPC bugs I find apart from the compiler crashes by partial
compile where reproducing is difficult, needs the whole MSEide+MSEgui source
and fixing probably would need construction of a new unit handling in FPC.
As the compiler sometimes
On Saturday 14 July 2012 19:55:39 Sven Barth wrote:
> >
> > 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
Am 14.07.2012 21:48 schrieb "Jonas Maebe" :
> I guess there are probably no such FPC-compiled programs yet (*), so
maybe now is the time to add that before we also get stuck with that
particular piece of ballast.
Somehow I have the feeling that we all know what one of your upcoming
commits will be
On 14 Jul 2012, at 20:52, Jonas Maebe wrote:
> On 14 Jul 2012, at 18:02, Martin Schreiber wrote:
>
>> I do not necessarily want to use field order optimization but if the FPC RTL
>> is compiled with it I need to compile my cracker classes with optimization
>> too.
>
> That's indeed true.
Tha
On 14 Jul 2012, at 20:29, Nico Erfurth wrote:
> So basically, something like
>
> class MyClass = class
> {$OPTIMIZATION OFF}
> private
>FHeavilyUsedValue: Boolean;
>FAlsoHeavilyUsedValue: DWord;
> {$OPTIMIZATION DEFAULT}
>NotOftenUsed: Byte;
> end;
>
> should leave the ordering of
On 14 Jul 2012, at 18:02, Martin Schreiber wrote:
> I do not necessarily want to use field order optimization but if the FPC RTL
> is compiled with it I need to compile my cracker classes with optimization
> too.
That's indeed true.
Jonas___
fpc-de
On 14.07.12 01:44, Jonas Maebe wrote:
> 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 ord
Am 14.07.2012 01:44, schrieb 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
Am 14.07.2012 07:45 schrieb "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
On Saturday 14 July 2012 14:07:30 Jonas Maebe wrote:
>
> > 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 neces
On Saturday 14 July 2012 14:26:32 Michael Van Canneyt wrote:
> > If would you want to use that optimization, then yes. "Working around"
> > the type system of the language is however generally asking for trouble,
> > regardless of what reason you do it for.
>
> Indeed. Maybe we can help by making s
On Sat, 14 Jul 2012, Jonas Maebe wrote:
On 14 Jul 2012, at 08:00, Martin Schreiber wrote:
On Saturday 14 July 2012 07:50:58 Martin Schreiber wrote:
On Saturday 14 July 2012 01:44:39 Jonas Maebe wrote:
I've implemented an optimization that reorders the instance fields of
Delphi-style class
On 14 Jul 2012, at 08:00, Martin Schreiber wrote:
> On Saturday 14 July 2012 07:50:58 Martin Schreiber wrote:
>> On Saturday 14 July 2012 01:44:39 Jonas Maebe wrote:
>>> I've implemented an optimization that reorders the instance fields of
>>> Delphi-style classes (and only of Delphi-style classe
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 al
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 yo
On Jul 13, 2012, at 6:44 PM, 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
> w
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 co
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 c
59 matches
Mail list logo
