Shh... IT in progress.

Do you bloat your app?

User Rating: / 0
PoorBest 

As with all applications we have to take performance into account, part of our performance is storage/memory used for operations.

OK so I am not an all time guru and know everything, however I do know that for each data type within our applications we have to make informed decisions on what data types we will use. When dealling with XPO this is especially important as the data type we use within our application will ultimately end up choosing the type of data type in our database which will determine how much storage space is used and how well the database will perform.

As an example of how things can go wrong, recently I found an awesome code WTF in a Legacy database system I inherited. The Tax Rate is being stored as a Currency which the XPO Wizard has defined as a Decimal... now a Tax Rate is usually a nice small number such as 0.1 (10%) or say 0.11 (11%), again as stated I am not a guru so I did a quick search on Single Double Decimal to see what the difference is... I was shocked.

I found this blog post which is a great simple to the point explanation on what is what. http://techembassy.blogspot.com/2006/07/data-types-single-double-and-decimal.html and if you want some indepth information on Floating Points I recommend this http://www.extremeoptimization.com/resources/Articles/FPDotNetConceptsAndFormats.aspx

So this is basically telling us that a Single is a 32bit type, Double is 64bit and Decimal is 128bit. So if we consider the second article I linked, the "accuracy" of my tax rate only has to be to about 2 decimal places or a "precision" of 3 digits. Currently we have a Decimal defined so for this "small" number we are using 128bits (16 bytes) to store the Tax Rate, which when we look at a Transaction Table which should always store the "Rate" that was used to calculate it's sell price we end up with "ALOT" of bloat.

So in conclusion a Data Type of Single(Float) would do perfectly for my Tax Rate, but say for the Unit Sell Price which is the calculation of (CostPrice * Tax Rate) you might want to store it with higher precision, so a Double would be most likley more than "accurate" enough and you would have saved 1/2 the memory over a Decimal.

So I ask you, do you bloat your app?

Comments  

 

0 # Mark Chimes 2010-02-25 13:40

I have never considered this.

I assumed when I configured a decimal field to be (say) [6,3] that this reduced the space being taken up by the data.

Thanks for the tip.

Reply | Reply with quote | Quote

 

 

0 # Michael Proctor [Dx-Squad] 2010-02-25 13:49

Within your SQL it certainly will, however in your application there is memory concerns, also within XPO unless you specifically use the DBTypeAttribute it will generate fields using the following table:
www.devexpress.com/help/?document=Xpo/CustomDocument2003.htm

The other issue is, I believe XPO doesn't allow you to set the Precision of this field, so ultimately with a fresh database it will store with whatever the default precision is for the DB data type XPO uses.

I will admit that this is all a revelation for me too, as mentioned in the post I was going over a XPObject and saw the TaxRate at Decimal so I decided to do some research, after I picked myself up off the floor I decided to write this post.

Reply | Reply with quote | Quote

 

Refresh comments list
RSS feed for comments to this post.

Add comment

Although I believe your free to say what you want, please don't abuse either myself or other peoples, be constructive.

Name (required)

E-mail (required)

Notify me of follow-up comments

Refresh

Send

Cancel

JComments