Pavel Sanda wrote:
> but it should be possible to find the problematic line of
> tocwidget::updateview just by lyxerr timing output. the timing delay
> for single run of this function is noticeable even by eyes.
so i have tried.
i'm 100% sure that slowness is triggered by tocwidget::updateView,
when i set return in the beginning of the function after first 200
updates, first 200 chars are sloow, then it gets back to normal.
then i put lyxerr timing commands in more parts of this function, the result is:
16:57:50:494ms if (!gui_view_.documentBufferView()) {
16:57:50:495ms QAbstractItemModel * toc_model
16:57:50:495ms sortCB->blockSignals(true);
16:57:50:495ms depthSL->setMaximum(gui_view_.tocModels().depth(current_type_));
16:57:50:495ms !persistent_ && can_navigate_
16:57:50:498ms if (can_navigate_) {
16:57:50:498ms filterContents();
16:57:50:498ms end
(lyxerr output is always above the line cited).
this shows the only, but _very_ small timing delay is inside setTreeDepth
(495-498 line).
if i put return in the beginning of this function, the slowness does not
disappear. unless there is unprobable catch because of lyxerr processing
my conclussion is that updateView triggers this slowness, but this slowness
itself is in some internal and asynchronous qt processing later.
pavel
