Decode map will not hold the DataRows, only the "legend" to decode
them. So it is a flyweight (as in "flyweight pattern"). E.g.
Artist Decode Map:
"ARTIST_ID" -> 0
"ARTIST_NAME" -> 1
"DATE_OF_BIRTH" -> 2
Artist DataRow:
[1, 'Dali', '19...']
decodeMap // pointer to decodeMap
Andrus
On Mar 7, 2008, at 12:43 PM, Aristedes Maniatis wrote:
>
> On 06/03/2008, at 12:44 AM, Andrus Adamchik wrote:
>
>> This got me thinking about DataRow memory/creation efficiency
>> throughout the framework. We are wasting lots of space on repeating
>> information. Essentially a DataRow for each entity has a well
>> defined set of keys, so ideally we can normalize the storage of
>> DataRows internally, saving an Object[] of values with a reference
>> to a shared "decode map", one per entity. Such a shared map would
>> have DbAttribute names for the keys and array positions for the
>> values. What we'll lose is the ability to serialize DataRows (e.g.
>> for remote notifications), but maybe we can work around it somehow.
>
> How does this interact with the DataDomain snapshot cache? You've
> explained that this cache is Map<ObjectId, DataRow> but it has an
> LRU expiry policy. What happens with a DataRow which is expired from
> the DataDomain but still exists in the 'decode map'? Is it possible
> to merge the two concepts (snapshot cache and decode map) as long as
> there was a more sophisticated expiry policy?
>
> The big benefit to reducing memory usage is that users will be able
> to create larger caches and improve performance.
>
>
> Ari
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
This archive was generated by hypermail 2.0.0 : Fri Mar 07 2008 - 06:24:33 EST