[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Nested hash-tables, and so on..

From: Kon Lovett
Subject: Re: [Chicken-users] Nested hash-tables, and so on..
Date: Sun, 9 Feb 2014 11:50:22 -0800

On Feb 9, 2014, at 11:12 AM, <address@hidden> wrote:

> On Sun, Feb 09, 2014 at 03:29:09PM +0100, mfv wrote:
>> Hi, 
>> I've been fooling around a bit with chicken, and now I am on towards a small
>> project. I have a question regarding the performance of list and
>> hash-tables.
>> I plan to use nested hash tables as a data structure e.g.
>> hash-table1
>>          |
>>          key1
>>             |
>>             hash-table2
>>                       |
>>                       key2
>>                          |
>>                          list/string/some data
>> Are there objections to such a nested hash table structure e.g. should one
>> keep it as flat as possible and use multiple hash-table is parallel  in 
>> order to maximize performance?
> In non-scheme languages, I use this technique a lot.  It's a poor
> man's struct, and when you don't exactly know what problem you're
> solving yet, that's precisely the data structure you need.
> If you're worried about multiple hash table lookups, you can create
> a composite key: pick a character/object that won't appear in key1..n,
> and use it as a separator, joining and splitting your key to convert
> it to/from it's composite.  I've rarely used this technique, compared
> to the above above nested hash tables, so I suspect that nested
> hashing will be adequate to solving the problem you have in mind.

Any Scheme object can be hashed w/ the SRFI 69 "equal?-hash" function. So a 
composite key represented as a pair/list, vector, or record is feasible. 

> I don't believe there is anything fundamentally wrong with your
> approach.
> -a
> -- 
> my personal website:
> _______________________________________________
> Chicken-users mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]