• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • How much memory is used by certain standard PB data types?

Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (2)

Resolved How much memory is used by certain standard PB data types?

  1. Misc
0
Votes
Undo
  1. John Fauss
    John Fauss
  2. PowerBuilder
  3. Wednesday, 20 February 2019 03:08 AM UTC

How much memory is used by each of the following standard data types?

  • Date
  • Time
  • Datetime
  • Real
  • Double
  • Decimal

 

  1. DataType
  2. Memory
  3. PowerBuilder
Stock icon for DW buttons
Oracle 12c cannot connect through Powerbuilder 201...
Responses (2)
Roland Smith
Roland Smith Accepted Answer Pending Moderation
  1. Sunday, 24 February 2019 02:13 AM UTC
  2. PowerBuilder
  3. # 1

I would think that the answer would either be 4 or 8 for most of them.

Comment
John Fauss
  1. John Fauss
  2. Tuesday, 26 February 2019 02:21 AM UTC
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!

  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 20 February 2019 20:06 PM UTC
  2. PowerBuilder
  3. # 2

Hi John;

    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
  • .Describe("DataWindow.Storage")

    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.

For example:

     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.

HTH

Regards ... Chris

Comment
John Fauss
  1. John Fauss
  2. Thursday, 21 February 2019 04:58 AM UTC
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!
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Thursday, 21 February 2019 16:22 PM UTC
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!

  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.