[Geany-Devel] Geany performance

[Matthew Brush]

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(..)
>> .............
>>     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.
>

Agreed, just somebody has to do it :)

Call graph for document_open_file():
http://www.pasteall.org/pic/show.php?id=60033

Cheers,
Matthew Brush