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 _______________________________________________ vala-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/vala-list
