[Geany-Devel] Geany performance

[Thomas Martitz]

Am 29.09.2013 03:26, schrieb Pavel Roschin:
> Geany is very fast of course:) But we could make it faster
>
> I use excellent runtime profiler named crxprof. It helped me to find one
> bottleneck in geany's starting logic:
>
> main (100.0% | 0.0% self)
>   \_ configuration_open_files (55.5% | 0.0% self)
>   | \_ document_open_file_full (55.4% | 0.0% self)
>   |   \_ editor_goto_pos (29.7% | 0.0% self)
>   |     \_ sci_goto_pos (29.5% | 0.0% self)
>   |       \_ ScintillaGTK::WndProc (29.5% | 0.0% self)
>   |         \_ Editor::WndProc (29.5% | 0.0% self)
>   |           \_ Editor::EnsureLineVisible (29.5% | 0.0% self)
>   |             \_ Editor::WrapLines (29.5% | 0.0% self)
>   |               \_ Editor::WrapOneLine (21.2% | 0.0% self)
>   |                 \_ Editor::LayoutLine (20.3% | 0.4% self)
>   |                   \_ PositionCache::MeasureWidths (19.0% | 0.3% self)
>   |                     \_ SurfaceImpl::MeasureWidths (18.7% | 0.4% self)
>   |                       \_ pango_layout_get_iter (16.1% | 1.1% self)
>   |                         \_ pango_itemize_with_base_dir (5.7% | 0.8% self)
>
> As you see, editor_goto_pos takes 1/3 of _loading_ time!
>
> But it shouldn't be called at least if position if 0, so adding simple
> optimization will improve loading speed:
>
> GeanyDocument *document_open_file_full(..)
> .............
> 	if(pos)
> 	{
> 		/* set the cursor position according to pos,
> 	cl_options.goto_line and cl_options.goto_column */ pos =
> 	set_cursor_position(doc->editor, pos); /* now bring the file in front */
> 		editor_goto_pos(doc->editor, pos, FALSE);
> 	}
>
> Not best solution but it works for me:
>
> Loading time before optimization: 8.952s
> Loading time after optimization: 5.799s
>
> Much better, isn't?


I'm surprised this costs so much time.

How did you test all this? Did you use a HDD, SDD or ram disk? I would 
expect that the heavy I/O for loading the documents from disk would 
cause most of the delay.


>
> Other proposals about loading speed:
> 1) Skip unnecessary operations for EACH document because actually user will see
> only LAST loaded document. Other operations could be delayed.


I agree that as much work as possible should be delayed to when the doc 
is displayed first or perhaps just to idle cycles. Doing the full blown 
initial work for each and every doc on startup is a huge scalability 
problem especially if the documents in question will not be displayed 
for a while (or in fact never be displayed).

I think doing all the initlal work by using g_idle_add and only make 
sure it's done asap for the finally displayed document (highest 
priority) would be a huge win.

Best regards.