Roland, for the most part, I think it's reasonable that a Real is represented in 4 bytes, a Double in 8 bytes, Time and Date values each in 4 bytes, and a Datetime in 8 bytes. However, I can't see how a Decimal value, which has up to 28 digits, sign and decimal point position could be represented in only 8 bytes...16 bytes, likely.
In the end, I would just like to see Engineering document this information officially, once and for all. Thanks for your input!
Well ... if memory serves me correctly (no pun intended here - LOL), that information is not well documented anywhere AFAIK. However, I do have a "sneaky" way to find out if you have some spare coding time. The DW object will actually give you that information via the command:
.Object.DataWindow.Storage // OR
Now what you would need to do is create one "external" DW object with one row and one column of the datatype from your question ... say for example "Decimal". Then at run time load the DWO and perform an InsertRow(0) plus SetItem(1, ). Then request the DWO to give up its used storage via the above command. That would now tell you the over-head of what a DWO does to handle one decimal value.
The above approach would not work though for native variables. You would have to instantiate say a Decimal variable and perform a "GlobalMemoryStatusEx" MS-Windows API call just before and after the variable type instantiation. The delta of course would be the native memory consumption for that variable type.
Sorry for that little bit of a long winded answer.
A very creative approach, Chris! I experimented this evening with the external source DataWindow Object and the DataWindow.Storage property, but the results are inconclusive. I also tried using a DataStore to see if there were any notable differences between a visible presentation (DW) and non-visual (DS).
In general, inserting the first row incurs a non-trivial increase in storage use of approx. 1700-2700 bytes varying between the datatype of column object and presentation (visual vs. non-visual) , which is, I suppose, understandable. Subsequent row additions consistently increased storage use by a fairly small amount (in the range of 104-120 bytes, depending on the datatype). I also compared storage use when adding a row without setting a value versus performing a SetItem after the InsertRow. I cannot draw any definitive conclusions from the results, and I'm doubtful that a standard datatype such as Decimal, Date, Time, & Datetime require 104-120 bytes of memory.
I will look into your suggestion on using the GlobalMemoryStatusEx Windows API tomorrow evening. Thanks again for the suggestions!
Yes, the DWO's storage overhead would also include Row & Column "state" flags plus space used in various buffers (Original + Primary). So 104-120 bytes for that per row seems realistic to me. Dividing that number in 1/2 would present the over-head in one buffer. The Row and State flags are 4 bytes each. So say 120 / 2 = 60 - 8 = 52 bytes. I am sure that there are some other internal overheads as well that are in there but, I do not know what they are specifically.
Thanks for that feedback and your hard work ... very interesting!