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,947 of 33,346    |
|    alan_mckenney1@this.is.invalid to Seungbeom Kim    |
|    Re: Sequence container capacity after ca    |
|    27 Mar 13 09:01:34    |
      On Wednesday, March 27, 2013 7:00:08 AM UTC-4, Seungbeom Kim wrote:              > You may be concerned this involves a deallocation and an allocation       > even when not necessary, but this has to happen many times in a       > tight loop to actually affect the performance, which I don't see       > very common.              You may not see it [the cost of allocation/deallocation] very often,       but it's pretty common to have to worry about it in the work I do.              We avoid using new and delete in the data processing phase of our       codes (it's OK in initialization) because when we do, our profiler       results show them being major CPU users. We avoid std::string for the       same reason. For that matter, we discovered that deleting a null       pointer had a pretty significant cost.              In fact, we use fixed-length arrays instead of std::vector if we know       the maximum length in advance, again, for performance reasons.[*] When       an extra 30% of performance can save you having to buy hardware that       costs a programmer's salary for a year, you care about all the stuff       that C++ gurus say doesn't matter any more.              [*] I really wish C++ would incorporate C99 variable-length arrays.       They would have _really_ simplified some sections of my code.                     --        [ 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