CubicDesign wrote:
> Ken Adam wrote:
>> Personally, I would declare it packed, use the types that are defined not to
>> change (as mentioned in another post), and then add 1 byte "reserved" to 
>> make sure
>> the structure remained a nice round 16 bytes long to preserve alignment, and 
>> accept that
>> this means that it will use 1/15 more disk space than necessary.
>
> So, because of this forced 16 bytes alignment the I will have no 
> performance penalty even if the records are packed. Right?

Right. In essence, you're re-creating the same alignment that the 
compiler would have used with your original unpacked record, but you're 
doing so in a controlled, predictable manner. If you leave it to the 
compiler, then your program is subject to changes in the compiler's 
alignment policies, and those have changed over the years.

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

He said "alternatively." That is, you would do one or the other, not 
both. Obviously, if you're padding the size of the record, there's no 
point in encoding the Boolean somewhere else. But the _alternative_ is 
to remove the Boolean field altogether by encoding that one bit of 
information in some other field instead. Then you're _removing_ one byte 
per record instead of adding one, and the packed alignment should be the 
same as the unpacked alignment.

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

Are you honestly saying that you think 40 KB is a substantial waste of 
memory?

-- 
Rob
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi

Reply via email to