I fired gprof to try to see whether updateLabel was as slow as Abdel
claims (by loading the user guide and repeateadly breaking and merging
a section paragraph to trigger renumber). The answer is:
[7] 85.0 0.00 25.80 249 lyx::updateLabels(lyx::Buffer const
&, bool) [7]
0.63 14.32 249/249 lyx::TocBackend::update() [8]
0.68 9.41 249/249 lyx::updateLabels(lyx::Buffer c
onst&, lyx::ParIterator&) <cycle 4> [16]
and
[8] 49.2 0.63 14.32 249 lyx::TocBackend::update() [8]
0.04 12.14 674914/674914 lyx::ParConstIterator::operator
++() [12]
0.24 1.03 2100811/2100811 lyx::ParConstIterator::operator
->() const [42]
0.04 0.32 675163/675163 lyx::operator!=(lyx::ParConstIt
erator const&, lyx::ParConstIterator const&) [88]
So, basically, 60% of the time spent in updateLabel is spent in
TocBackend::update. The said TocBackend::update call has been added at
some point by some sloppy Gremlin who thought that nobody would
notice.
So: updateLabel is fast. TocBackend::update is slow.
The later problem could be addressed by rewriting it like updateLabels
to avoid using ParConstIterator. This is as easy as defining a
InsetText::addToToc (and a InsetLabel::addToToc, maybe).
However, I wonder whether the best solution would not be to merge the
two functions in order to maintain an über-ToC, containing also
enumerations and such niceties. This would also allow to remember
counters and do local-only renumbers.
JMarc
