On 13-09-29 12:23 AM, Павел Рощин wrote:
IIUC what you are seeing here is Scintilla laying out the window for the
first time, not just the goto. That still will be done if the
editor_goto_pos is not called, just from a delayed idle callback IIUC. If
its in the order of 3 seconds then I'm not sure delaying it is really going
to improve the user experience (even though it moves the action out of the
function you are measuring :)
Profiling shows that loading time was reduced dramatically. And I feel that
difference as user.
This now ignores the cl_options settings since it doesn't call
set_cursor_position() any more :(
It doesn't _only_ if pos == 0. Go to zero position? Imagine I'm trying to load
project with 1000 files. For each document set_cursor_position(0) will be
called. Why?
Possibly, but you have to ensure that the actions actually happen at some
point. Sure you don't have to layout the hidden windows immediately, but
does that mean that the first time you swap to a hidden file is slow?
This is the thing called interface responsiveness. For user it's _much_ better
to wait 0.02 sec 1000 times when clicking on document than wait 20 sec on
loading. Most JIT compilers based on this trick: JIT compiler "delays" hot
loops preferring execution over compiling.
It is difficult, it has been discussed many times, but neither Geany, nor
Ctags, nor tagmanager, nor GTK are thread safe and it would take a major
re-design to use them from multiple threads.
I see, but it could be a great improvement. Maybe even make co-routines but in
multicore world it sounds surprisingly.
Basically the same problem as number 1), plus the difficulty of maintaining
which tabs are loaded and laid out.
Same answer: responsiveness and again responsiveness. I'm human, if computer
thinks 0.1 sec - I will even don't notice, if interface holds for 10 sec - it
makes me nervous. Maintaining should simple: just add flag "delayed_load" and
toggle it first time user clicked on document. Of course if there are no
architecture problems.
Sad as I am to say it, but maybe those with 1000s of tabs need a different
editor/ide, Geany's target is "small lightweight and simple" and it is
important that it maintains its focus on that.
I tried Eclipse. Without plugins it's functionality is similar to Notepad++ but
it eats 0.5 Gb of memory even without any project. To support all languages I
need for I should download thousands of plugins and now it eatch 1.5 Gb.
QtCreator is a good but... C++ only. Recently Python was added.
I need Geany for my work - it's huge project and I should handle over 10 million
of files with different languages - from TeX to C++. Either I have to open 100-s
of IDE or I can use Geany. I know there are much to do, I'm sure I could help
with developing but let's start with this simple improvement? I'll make PR if
it's easier for you.
Hi,
Just to be clear, all of the stuff discussed here with respect to lazy
loading and not blocking the UI is considered serious issues by all of
the core developers of Geany, we have bikeshedded over it a lot, it's
just that the changes required to make it a reality are very much
non-trivial. It is engrained in Geany's DNA that global shared data is
OK and that only one instance of Geany will ever be running on one
single CPU core. I'm not saying it's good, or OK, but it *is*.
Patches fixing the situation are highly encouraged.
Cheers,
Matthew Brush
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
