[Geany-Devel] Geany performance
thomas.martitz at xxxxx
Sun Sep 29 20:02:23 UTC 2013
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(..)
> /* 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.
More information about the Devel