home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!usenet.ins.cwru.edu!agate!spool.mu.edu!howland.reston.ans.net!paladin.american.edu!news.univie.ac.at!hp4at!mcsun!julienas!corton!ilog!davis
- From: davis@passy.ilog.fr (Harley Davis)
- Newsgroups: comp.lang.scheme
- Subject: Re: How to lookup symbols fast?
- Message-ID: <DAVIS.93Jan24152042@passy.ilog.fr>
- Date: 24 Jan 93 14:20:42 GMT
- References: <1je4kvINN5cj@shelley.u.washington.edu>
- <1993Jan19.212543.29200@gallant.apple.com>
- <JAFFER.93Jan20163704@camelot.ai.mit.edu>
- Sender: news@ilog.fr
- Organization: ILOG S.A., Gentilly, France
- Lines: 29
- In-reply-to: jaffer@zurich.ai.mit.edu's message of 20 Jan 93 21:37:04 GMT
-
-
- In article <JAFFER.93Jan20163704@camelot.ai.mit.edu> jaffer@zurich.ai.mit.edu (Aubrey Jaffer) writes:
-
- (Kenneth Dickey) writes:
- ...
- >Is there anything better than a simple linear search of the
- >symbols?
-
- The rule of thumb is "for less than 100 elements, linear search beats
- hashing". For 30 entries use an alist & assq.
-
- I tested this out. The break-even for SCM using SLIB is 250 elements.
- The situation for compiled code would be less (perhaps 100). Here is
- my code. I used strings instead of symbols so that hash.scm would use
- OBJECT-HASH. It is much slower for symbols. In light of this result,
- I will be changing some of my code back to using alists.
-
- This kind of measure is so totally implementation-dependent that
- general "rules of thumb" are out of line. For example, in Le-Lisp
- version 16, the break-even point for symbols as keys is a giant 2
- elements in the a-list.
-
- -- Harley Davis
- --
-
- ------------------------------------------------------------------------------
- nom: Harley Davis ILOG S.A.
- net: davis@ilog.fr 2 Avenue Gallie'ni, BP 85
- tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France
-