CubicDesign wrote:
>So, because of this forced 16 bytes alignment the I will have no
>performance penalty even if the records are packed. Right?
If performance is critical (you MUST measure the performance change for
your application to assess the impact!) then you can accept the extra
40kb of disk space and you should pack and pad the structure to make
sure that it will always be the same size (16 bytes). The CPU will not
then access misaligned data, so it will run each instruction most
efficiently.
However, the total size of your data and the pattern of accesses may mean
that the larger structure results in more cache misses which will impact
overall performance. (you really need to use something like
QueryPerformanceCounter and QueryPerformanceFrequency to get very precise
measurements of the impact. There is small unit (FastTime.pas) distributed
with JVCL that wraps these up in a simple object if you don't want to do
it yourself).
>> Alternatively I'd look at whether I really need to store the Boolean
>> separately, or could I pack it as 1 bit into one of the other fields.
>I don't see the point. If I add an extra byte to force the record length
>at 16, then I will have anyway an extra byte that is actually wasted.
>So there is no point to 'compress' that byte to 1 bit.
I meant this instead of adding the extra byte ("Alternatively").
If the space is critical, then look at packing the Boolean into one of the
other
fields so the structure is 14 bytes long (saving 80kb on the above case),
and accept that you need to extract this bit (could be as you load the file,
or if you don't access it much, just inspect it when you access it).
I don't advocate wasting memory unnecessarily - I started developing for
systems with memory measured in small numbers of kb, not Mb or Gb - but you
need to assess the relative importance of space/performance/development
time/supportability etc for your application.
>Inserting that extra byte will eat some memory because I have to load
>LOTS of those arrays in memory so the memory lost is substantial (length
>of the array is about 10000-40000 records). I will see later if the
>speed is more important than memory size.
The point about all this is that there is no single answer to your question.
In my case I was creating data for an embedded real-time avionic system,
(where I don't have the luxury of virtual memory) and so I had precise
constraints on memory usage and processing time.
For that system it made sense to pack a (rarely referenced) Boolean in a
spare bit of another value and mask the data on access (not on load/store).
This may or may not suit your application.
Regards,
Ken
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
