home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 32,915 of 33,346   
   James K. Lowden to Dave Harris   
   Re: insert [sorted] a node in a linked l   
   11 Mar 13 15:06:27   
   
   From: jklowden@speakeasy.net   
      
   On Sun, 10 Mar 2013 16:20:11 -0700 (PDT)   
   brangdonj@googlemail.com (Dave Harris) wrote:   
      
   > In article <20130309115333.e97f4363.jklowden@speakeasy.net>,   
   > jklowden@speakeasy.net (James K. Lowden) wrote:   
   > > A linked list is, from a theoretical standpoint, a perfectly   
   > > reasonable data structure for ordered data.  Sure, a binary tree   
   > > is faster to seek over.  But a list is perfectly adequate for   
   > > "small N, and N is usually small" as Rob Pike put it, and has   
   > > nothing like the complexity of a tree.   
   >   
   > I think for a long time it's been rare to beat a vector. If N is   
   > small, then the time taken to shuffle up elements when inserting   
   > in the middle will also be small. If you need to keep it sorted,   
   > that's trivial with the std library. As I recall, it's something   
   > like:   
   >   
   >     auto i = std::lower_bound( begin(v), end(v), item );   
   >     v.insert( i, item );   
      
   That was an interesting claim.  I wrote  a little test of my own which   
   supports it.   
      
   I inserted just 100,000 randomly generated integers in a std list,   
   vector, and set.  Not being a fan of O(n) performance, I'm not much of   
   a list user myself.  I was stunned at how slow it was:   
      
   list:		6m56.993s   
   vector:	0m1.388s   
   set: 		0m0.447s   
   empty: 	0m0.334s	(no container, just /dev/urandom)   
      
   Seven minutes versus 1 second.  Behold the power of the binary search!   
      
   On a machine operating at billions of instructions per second, std::list   
   manages less than 250 insertions per second.   
      
   Bumping N up to 250,000, skipping list and adding a deque,   
      
   deque:	real    0m25.088s   
   vector: 	real    0m7.258s   
   set: 		real    0m1.180s   
   empty: 	real    0m0.833s   
      
   which is a disappointing result for deque, if you ask me, but much to   
   your point: deque *should* be faster because inserts are cheaper, but   
   the effect of locality swamps it.   
      
   Nothing definitive, of course.  Just one program on one machine   
   using one compiler, run just a few times.  But it does look like   
   std::list is headed the way of the 9-track tape.   
      
   --jkl   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca