|
![](/i/fill.gif) |
Warp wrote:
> I was more referring to some things which in theory one shouldn't have
> to worry about,
Sure. And in theory, you shouldn't have to worry about what order you list
the tables to be joined in SQL. :-) More similar than you may think, I think.
> One concrete example which is a real shame with most C++ compilers is
> memory allocation/deallocation speed.
Yep. That has always been a bane. Lots of people try to write
special-purpose allocators just for their programs which still don't do as
well as a good GC mechanism, too. (I posted a bunch of links to the actual
research a few months back.)
Allocation performance has always been a problem even long before C++ was
around. You'd certainly think people would have gotten it right by now. I
wonder why it's so hard, tho? Is it attempts to avoid fragmentation or
something?
> Is this time spent into inserting elements and rebalancing the tree?
> No. It's mostly spent in allocating memory!
I remember programs on machines with no MMU (like the Amiga) which had to
deallocate its memory on exit, when you'd exit the program and it would
spend long seconds cleaning up its memory. Even nowadays, you can sometimes
hear the disk thrash while exiting if you've started paging. :-)
> However, when I run the modified program, it only takes 2.9 seconds.
It's cool to have a language where you can change that stuff without
screwing with the compiler, yes. :-)
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
![](/i/fill.gif) |