uClibc++ associative_base performance

Asier Llano Palacios a.llano at usyscom.com
Fri Jul 6 07:21:44 UTC 2007

El jue, 05-07-2007 a las 19:36 -0400, Garrett Kajmowicz escribió:
> On Wednesday 04 July 2007 03:18, Asier Llano Palacios wrote:

>  workload you would be running that would take that amount of time.  On a low 
> memory system (which is what uClibc++ is geared towards), it's hard to have 
> enough memory to have enough records that this should matter.  If it's a 
> matter of inner loop performance, you would be best either taking a reference 
> to the node that you are using over and over, or using iterators to go 
> through the entire contents.  Both should result in constant-time 
> performance.
> If you have a very large amount of memory to the point that you are able to 
> fill up a very large data set than I would suggest going with libstdc++ - it 
> has algorithms that are optimized for speed whereas I went for readability 
> (at least in my own mind) and size.

I have about a thousand elements of about 60 bytes, but that change very
dynamically. I can afford 60 Kbytes of memory, but I cannot afford
having libstdc++, and I still need performance.

> I'm happy to consider any contribution that you would like to make. 

I'm nearly finishing it, and when I have it finished I'll post it. I'll
try to have a low impact in binary size and memory size. It will be a
bit more complex than a linked list (but not much bigger).

> I personally have objections to using a license similar to BSD or X11.  One 
> person has made the argument that I should instead be using the GPL with 
> linking exception (same thing that libstdc++ uses), but I haven't bothered 
> converting as of yet.

I'll contribute it under LGPL, for you to include it easily.

> <snark>
> It is so privileged that you sent it to a publically accessible mailing list 
> with a published public archive?  Unencrypted?  Wow.  And I was just starting 
> to think that you knew what you were talking about.  I like the bit about how 
> I'm supposed to know to "destroy it without review" the document when the 
> super-secret stamp is attached at the bottom.
> Finally, the message is scanned for viruses, but you disclaim liability.  Why 
> tell me this?  And if somehow the document contained a virus in the main 
> message (as opposed to an attachment) would I then be able to sue you because 
> your disclaimer doesn't cover it?
> *sigh*
> </snark>

Sorry about the disclaimer. It is included automatically by the mail
server of my enterprise. It is somehow disgusting to mail to public
lists, with it always attached, but I don't know the way to work around

Thank you.
----------------------------------------- PLEASE NOTE -------------------------------------------
This message, along with any attachments, may be confidential or legally privileged. 
It is intended only for the named person(s), who is/are the only authorized recipients.
If this message has reached you in error, kindly destroy it without review and notify the sender immediately.
Thank you for your help.
µSysCom uses virus scanning software but excludes any liability for viruses contained in any attachment.
------------------------------------ ROGAMOS LEA ESTE TEXTO -------------------------------
Este mensaje y sus anexos pueden contener información confidencial y/o con derecho legal. 
Está dirigido únicamente a la/s persona/s o entidad/es reseñadas como único destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elimínelo sin revisarlo ni reenviarlo y notifíquelo inmediatamente al remitente. Gracias por su colaboración.  
µSysCom utiliza software antivirus, pero no se hace responsable de los virus contenidos en los ficheros anexos.

More information about the uClibc mailing list