Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index


In the stackoverflow question "What does enabling STL iterator
debugging really do?" [1], the top answer points out that creation and
destruction of STL iterators in debug mode is comparatively expensive.
The example given in the answer is:
    for (iterator_t it = vec.begin();
         it != vec.end();              // Oups
         ++it)
    // body
LibreOffice has quite a number of loops written this way.  Do we care?

My builds with --enable-dbgutil are noticeably slow, but (a) that
build option does other things, too; (b) my machine is very
underpowered for this task; and (c) most people do not use debug
builds.  So, possibly we do not care.  OTOH, hoisting vec.end() so
that is is called only once should be a quite mechanical task, even a
candidate for an easyhack.

FWIW, the output from 
    git grep --extended-regexp '((for)|(while)) *\(.*\. *end\('
was 2974 lines when I looked at it.  An examination of 13 lines from
the output shows that 10 of them evaluate end() in each iteration.
Measurement of the actual cost in performance is beyond my capability.

Just for reference, note the thread on the this list "General question
about vectors" [2], which discusses the choice between `for` loops and
`for_each` calls.

Thoughts?

Terry.

References:
[1] <http://stackoverflow.com/questions/2731419/what-does-enabling-stl-iterator-debugging-really-do>
[2] <http://nabble.documentfoundation.org/General-question-about-vectors-td4094114.html>



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.