[fpc-devel] Class field reordering
mse00000 at gmail.com
Wed Jul 18 08:19:02 CEST 2012
On Tuesday 17 July 2012 09:40:36 michael.vancanneyt at 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 buffer. The slot contains an index, pointing
> to a separate array of strings containing N*M*2 strings. (N=number of
> records, M= Number of string fields per record, factor 2 for old values)
> Field value = Element [Index [+1 for old value]] in the array.
> where the [Index] is stored in the buffer.
> The speed performance penalty of this system should be negligable, since
> you assume all records are in memory anyway.
> And: everything can be done without meddling with the internals of TField.
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 my eyes not optimal solutions. With
a forked db.pas I can eliminate the many workarounds I already had to
Currently needed crackerclasses by MSEide+MSEgui:
Used by MSEide for different tasks (example: ask for ancestor forms and
frames/submodules while loading a form/datamodule, recover in case of an
error) and for streaming of frames with additional components/widgets:
Used in order TParams create tmseparam items instead of TParam:
Used to unify memorystreams/files/pipes/sockets/stringstreams:
Why must these fields be private?
More information about the fpc-devel