[Vala] R: Re: R: The perfect Vala/GNOME IDE...

["sejerpz tin it" <sejerpz tin it>]

Hi,

> Can you name the bottleneck that makes it slow at loading time?


Yes, it's the symbol resolving step that takes a lot of time, but 
there's more.

The first version of afrodite uses one separated thread 
for parsing / resolving this was the right thing to do, but complicated 
the api since the consumer should acquire a lock to query the symbol 
structure.
While still slow, this approach was right because it doesn't 
impact the user experience and gedit was still responsive while parsing 
the files.

In the following afrodite versions, in order to simplify 
the api I changed this model to single thread using async methods and 
throttiling the parser / resolver step.
The result was a slowdown of 
the parsing / symbol resolving process and since all of this is CPU 
bound and executed in main gedit thread the user experience was 
somewhat compromised.
In a word a big big FAIL :)

To fix this 
situation I think that I should:

1) Revert the parsing / symbol 
resolving to use another thread
2) To still have a simple client API, 
use a transactional data structure where we have 1 reading thread 
(gedit that query the completion data) and 1 writing thread (the 
parser/symbol resolver). More on this later.
3) Optional: cache the 
parsing / symbol resolving data structure and invalidate it only when a 
file is changed. This will speed up all the vapis: think about gtk+ 
3.0, glib that are parsed everytime one opens a project.


To solve 
point 2 and may be implement point 3 I planned to do some experiment 
with sqlite as a backend, first as an in-memory database, than as a 
cache db stored in the project folder to speed up the open phase.


That's all, and thank for your words about VTG, that, when it works ;) 
, I think it's really useful and it does its job.

Ciao,
Andrea