String Attribute lengths

[ConvertFromOldNGs]

by Stephen Persson >> Wed, 15 Nov 2000 22:47:00 GMT

Hi,
I just had a thought as to why I bother to set the length when creating a string attribute, rather than setting it to maximum length. (Except if the field is to be a dictionary key in which case I realise it can't be maximum length).

Heres how I understand it works:
Say I create a field for a Street Address. If a length is specified (say 60) then 60 bytes of space is reserved for this field regardless of its actual value. Even if the address is only 10 bytes, 60 bytes of space is taken up for this field.
As I understand it though, if I set the length to maximum, Jade does not reserve any space for the field, and the storage space used, is only ever exactly what is required for each particular instance.

So why do we even bother to set the length on string fields that aren't a dictionary key?
It seems to me to be a waste of space (sure disk space is cheap, but thats not really the point!), and you have to also then make sure the user can't/doesn't enter to much data.

I'm assuming therefore there must be performance issues related to setting string field to maximum length - true?

Stephen Persson
Kinetix Group Ltd

[ConvertFromOldNGs]

by Craig Shearer >> Wed, 15 Nov 2000 23:10:06 GMT

Yep, performance would be the reason. There is obviously more overhead in managing a slob than in managing a fixed piece of memory. Perhaps someone from the plant could comment on the actual overheads in managing these independent objects.

Craig.

[ConvertFromOldNGs]

by Eric Peachey >> Thu, 16 Nov 2000 1:24:22 GMT

As I understand it though, if I set the length to maximum, Jade does not reserve any space for the field, and the storage space used, is only ever exactly what is required for each particular instance.

There was a bit published on this kind of thing in the Jade 4.1 product information document. SLOBs and BLOBs were segmented and had a fixed 24 byte header. Don't know if this is still current. You could dig out your old CDs and have a look for the relevant doc. or see if anybody who knows posts a response.

Good luck,

[ConvertFromOldNGs]

by Abduhl >> Fri, 17 Nov 2000 4:08:23 GMT

Yes, there are certain performance issues to consider when deciding between using fixed length and unbounded string/binary attributes.

When you define a string or binary attribute that has a fixed length <= 540 bytes, the attribute value is embedded in the object. Embedded attributes are carried around with the object, so that once the object has been fetched to a given cache location further 'fetches' are not required to access them.

String and binary attributes defined with an unbounded length or length > 540 bytes are represented in the database as objects, sometimes referred to as slobs and blobs (string or binary large object). Such slobs and blobs are individual objects with their own unique OID (object identifier), that like exclusive collections are not embedded in the parent object, as such they are known as subobjects.

The main performance cost with slobs and blobs is the cost of fetching and storing an additional object. Consider read access to a persistent object from a client node: when an object with a slob attribute is fetched into cache on the client node, the slob doesn't come with it (which is good if you don't need to access the slob).When the slob attribute is first referenced another request to the server is required to fetch the slob, this in turn may require a fetch from disk (if the slob is not in db cache), which will incur a database index lookup to convert the oid to a disk address (zero, one or more disk reads). Contrast all this additional overhead with the negligible overhead of accessing an embedded attribute.

There are also some storage costs to consider when using slob/blob attributes:
1) Each slob/blob attribute is allocated 8 bytes in the parent object to store the length and edition of the blob/slob
2) A slob or blob has a minimum allocation size on disk and in memory; the minimum size of a blob or slob on disk is 91 bytes for the object (around 40 bytes in memory), plus some additional space in a btree index (minimum 10 + 4 + 8 bytes entry size). That means if you store 1 character in a slob it will require 121 (8 + 91 + 22) bytes of disk storage.

In summary, for performance reasons, I would recommend defining fixed-length embedded attributes were possible and use slobs and blobs to store arbitrary length data and/or infrequently accessed attributes.

[ConvertFromOldNGs]

by John Porter >> Fri, 17 Nov 2000 4:33:28 GMT

Thanks for the detailed response, Abduhl. What about local Strings in methods - any difference between fixed and unbounded?

Cheers,
John P

[ConvertFromOldNGs]

by Abduhl >> Fri, 17 Nov 2000 5:58:20 GMT

Thanks for the detailed response, Abduhl. What about local Strings in methods - any difference between fixed and unbounded?

John,

For the answer to that I will refer you to a response from Krull in the thread 'Faster local string variables' in jade_tech_tip_techniques. For your convenience here is the original question and the response in full (I have taken the liberty of correting a typo I spotted in the response):

Question:

Does anyone know if its faster in Jade to write

vars
s : String[40];

rather than

vars
s : String;

It would seem reasonable that Jade could be faster with the first version as It knows how much space it has to allocate.

Anyone know for sure?

Krull's Response:

The physical storage for String variables is increased in multiples of 32 character increments (a character is 1 byte in an ANSI build and 2 in UNICODE). The only real differences between a restricted length and unbounded string are a) The restricted length string has the minimum of 64 or declared max length characters of storage preallocated b) Restricted length strings are subject to bounds checking, that is if you exceed the declared maximum size a 'string too long' exception is raised.

In your example declaration s : String[40], the string variable will have 64 characters of internal storage allocated up front, whereas if you store 40 characters in an unbounded string variable, it could start with either 32 characters growing to 64 in 1 increment, or 64 characters depending on the size of the string value first assigned to it. Beyond the initial 64 character initial size, both types of string are grown dynamically up to their defined upper limit in multiples of 32 characters. The handling of dynamic storage allocation for binary variables is the same but units are always bytes. For short strings (where short means <= 64 characters), defining a fixed length results in more efficient storage; however, be aware that physical implementations are subject to change.

[ConvertFromOldNGs]

by Abduhl >> Fri, 17 Nov 2000 6:00:14 GMT

convenience here is the original question and the response in full (I have taken the liberty of correting a typo I spotted in the response):

or rather trading one typo for another - ha ha ;<