As Jim says, there is ordering involved, which is why I was using lists. But now I have thought about it some more, the ordering is only in one dimension, not two. To elucidate, there are heterogeneous objects of type X, and each object Xn has some numerical data, plus an ordered list of heterogeneous objects of type Y associated with it. The type X objects needn't be accessed in order and so a hash would work well. The type Y objects would always be accessed sequentially as either the whole list would be output in order, or a new entry would be added to the list at a point determined by an algorithm which partly depends on a sum of values of objects in the list up to the entry point.
Pete's idea of using the Ns_Cache() functions looks ideal. As I understand it, when you call Ns_CacheCreateSz(), you specify the maximum size of the cache that you want and then Ns_CacheMalloc() allocates memory from that cache. I then have some questions: 1. Apart from the limitations of main memory, is there a limit to the number of caches I can have? Could I have, say, 1000 caches of 8k each? 2. Is the memory allocated on executing Ns_CacheCreateSz() contiguous? 3. Is there a way of deleting a cache once it is no longer needed? In the online documentation, I can see Ns_CacheDeleteEntry() but that refers to the cache entries and not the cache itself. 4. As an alternative to 3, is it possible to re-name a Cache after it has been created? Thanks for the help, Jason On Mon, 15 Apr 2002 08:06:31 -0700, Jim Wilcoxson <[EMAIL PROTECTED]> wrote: >When there is ordering involved, as Jason mentions, hashes/arrays don't >work so great. Random access to an arbitrary element is fast, but there >has to be another data structure to remember the order. > >Lots of times we combine the two: put the data in hashes/arrays with keys, >then keep a list containing the keys in the order you want. This lets us >store lots of data with each key without keeping all of it in a list, >access it randomly very fast, and also access it sequentially in order(s). > >Jim > >> >> To answer your question, there's no way to avoid the "Tcl tax" in >> AOLserver. But maybe that's not a bad thing. >> >> The linked lists are setting off warning alarms in my head. Linked lists >> are terrific if most of what you do is accessing your data items in a >> serialized stream, but if you are going to be accessing an item here or an >> item there, you'll waste a lot of time traversing the list getting to the >> item you want (unless your lists are very short), as compared with using >> something else like, say, a hash. But you don't want to implement hashes, >> you say? As it turns out, Tcl is not just an interpreter, it's a library, >> and you can create hashes from C and maintain them, all without ever >> messing with any actual Tcl language stuff. And the Tcl libraries are >> pretty good about bucket management and garbage collection when you use >> them to manage your hashes. Since you haven't told us much about your >> underlying problem, I can't really say that linked lists are inappropriate >> as a solution, but you should take a look at the functions in the Tcl >> libraries related to hashes and see if they might serve your needs better. >> Also, I think AOLserver has C-based cache functions which allow you to >> dedicate a chunk of memory to a hash-based cache, which might be even more >> stuff you can use. >> >> (No idea about ColdStore, sorry.) >> >> Pete. >> >> On Sunday, April 14, 2002, at 10:32 PM, Jason Saunders wrote: >> >> > I'm designing a site written entirely in C-based modules - much of the >> > work >> > the modules do involves storing and reading small items of data (in the >> > order of 40 bytes) in linked lists. The data will also stored in a >> > database >> > for backup, and for more general access. The reason to store it in linked >> > lists is that it will be faster to store it in sorted form and then read >> > directly from main memory, rather than read it from a database, sort it, >> > build a linked list, manipulate the data, write to the database and then >> > free the list. >>
