[Geany-Devel] Geany performance
mbrush at xxxxx
Sun Sep 29 23:06:44 UTC 2013
On 13-09-29 01:02 PM, Thomas Martitz wrote:
> 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.
Agreed, just somebody has to do it :)
Call graph for document_open_file():
More information about the Devel