From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac39a12d5faf5b14 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-24 12:51:45 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!news-out.newsfeeds.com!propagator2-maxim!propagator-maxim!news-in.spamkiller.net!newsfeed.sjc.globix.net!hub1.meganetnews.com!hub1.nntpserver.com!peer1-sjc1.usenetserver.com!usenetserver.com!pd2nf1so.cg.shawcable.net!residential.shaw.ca!news-out.spamkiller.net!propagator-la!news-in-la.newsfeeds.com!news-in.superfeed.net!dax.net!juliett.dax.net!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Grace and Maps (was Re: Development process in the Ada community) References: <3CB46975.90408@snafu.de> <3CBAFFEE.2080708@snafu.de> <4519e058.0204171036.6f0a7394@posting.google.com> <3CBDD795.4060706@snafu.de> <4519e058.0204180800.44fac012@posting.google.com> <3CBF0341.8020406@mail.com> <4519e058.0204190529.559a47ae@posting.google.com> <3CC1C6B3.6060306@telepath.com> <3CC21747.5000501@telepath.com> <4519e058.0204220534.2eb33730@posting.go <3CC6EA85.CA2735B2@boeing.com> From: Ole-Hjalmar Kristensen Message-ID: <7vu1q0vpsj.fsf@vlinux.voxelvision.no> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Apr 2002 19:51:09 GMT NNTP-Posting-Host: 193.216.12.150 X-Complaints-To: abuse@tele2.no X-Trace: juliett.dax.net 1019677869 193.216.12.150 (Wed, 24 Apr 2002 21:51:09 MET DST) NNTP-Posting-Date: Wed, 24 Apr 2002 21:51:09 MET DST Organization: Tele2 Norway AS Public Access Xref: archiver1.google.com comp.lang.ada:23078 Date: 2002-04-24T19:51:09+00:00 List-Id: Jeffrey Carter writes: > As for timing, Pugh compares the CPU time of skip lists against several > kinds of balanced trees. Skip lists are about as fast or faster than the > trees for searching, and faster than the trees for insert/delete. > http://www.csihq.com/analysis/skiplist.pdf compares insertion times in > skip lists to B-trees (N=50,000 to 950,000 in 50,000 steps) and found > that Unix system time increased exponentially for N>=600,000, while it > increased linearly for skip lists, indicating that large B-trees did > significantly. Considering only Unix CPU time, skip lists were 5-10 > times as fast as B-trees; an order of magnitude is not a "touch" slower. > This benchmark is a bit strange, in that it compares the performance of a structure specifically tuned for use on disk (if indeed the B-tree it refers to is the same as defined by Bayer & McCreight) with the skip list, which is intented for in-memory use. Do you know if anyone has bechmarked or analysed the performance of a skip list if it were to reside on disk? I'm not arguing against skip lists, just curious if it might be a viable alternative to B-trees for disk based storage. > > I'd be interested in hearing what the advantages of the skip-list are > > over trees, other than slightly simpler code. Is it just the > > performance? (Which is, of course, important.) > > Between the significantly simpler algorithms, which are more likely to > be implemented correctly, and the observed performance advantages of > skip lists, the choice seems obvious. > > -- > Jeffrey Carter