On 10/22/2016 01:39 PM, Guillaume Munch wrote: > Le 18/10/2016 à 21:44, Guillaume Munch a écrit : >> >> Profiling shows that calls to BufferParams::isExportableFormat >> are numerous and expensive when doing char-forward (33% of the total >> amount of CPU). This is called from GuiView::updateToolbars -> >> GuiView::getStatus. There is room for improvement, but this is not new >> behaviour apparently. >> >> I also found that calls to TabWorkArea::updateTabTexts are >> expensive and repeatedb. This amounts to 31% of the total amount of CPU, >> shared between QTabWidget::setTabText and QTabWidget::setTabIcon. >> TabWorkArea::updateTabTexts is connected to the signal >> GuiWorkArea::titleChanged. >> > > > After improvements by Richard and Jean-Marc, GuiView::getStatus is down > to 10% (mostly lyx::to_utf8) and there is no trace of tabs updating.
Many of the to_utf8 calls are probably "FIXME Unicode", too. > New bottlenecks are Buffer::updateMacros (25%, of course depends on > the document) and nothing else looks really out of place. You can > celebrate. I've long wondered whether the updateMacros call in BufferView::processUpdateFlags is really necessary. As I say in a FIXME there: We call updateMacros in updateBuffer, and if the Buffer doesn't need updating, will the macros? I'm morally certain, at least, that we could at least include another flag that would tell us if they did need updating. But I don't know enough about the macro machinery to be sure when they do and when they do not. That said, if anyone is brave enough to do so, we could try commenting that line out and see what happens. Richard
