I know they use hash tables for symbols, but I've always assumed "lists" to be doubly-linked lists, because that nearly exactly mirrors the functionality they offer. And if you correct my "bytes" into "bits" (sorry, it was getting late at night or something), then I think the total was:
4 bytes "Item" (e.g.: pointer to data) 4 bytes "Type" (e.g.: indicator int, string, etc.) 4 bytes ptr next 4 bytes ptr last -- 16 bytes total If a property list, then another 8 bytes Total: 24 bytes is my estimate for a property list, not including actual data. Not much overhead, imo. - Tab At 10:09 AM 9/9/02, Mayuresh wrote: >My First impression of a list was that they were implemented using linked >lists. A doubly linked list would certainly be robust which seems to be >the case since list implementation rarely breaks. That would be the more >straight forward way, though not the fastest as Robert pointed out. >Hash table IMO would be when your indexing data and need to perform some >serious quick searches something which I have not really experienced with >lists. > >Though I can't think of a way to calculate how much each list or every >element from a list hogs, but I doubt if it's so much for a reasonably >sized list to seriously affect performance. > >Maybe MM can help out. > >Mayuresh [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
