Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
The "Generate tags for all project files" causes this massive delay, but I really need that feature.
At work I have a 2-core CPU, where 1 is completely idle and on my desktop at home there are 5 cores are doing nothing while generating tags. Can't they be utilized to speed up the tag generation?
Cheers!
Harold
Hi,
Le 07/11/2011 16:35, Harold Aling a écrit :
Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
The "Generate tags for all project files" causes this massive delay, but I really need that feature.
At work I have a 2-core CPU, where 1 is completely idle and on my desktop at home there are 5 cores are doing nothing while generating tags. Can't they be utilized to speed up the tag generation?
TL;DR: it's really not that easy.
Long story:
The tag parsers cannot use more than one thread, but we could imagine running more than one at the same time in different threads. Not sure what is Geany's and GProject deal here, so I'll speak about Geany; Jiřì could probably answer about the GProject part.
Well so, running the parser in it own thread. It's a good idea I already tries to implement for real-time tag parsing (for it to be not intrusive in the parsing part), but it's not easy. We need two things:
1) A function that can run the parser and notify when done. 2) Collect some return value and data 3) Make sure nothing is accessed at the same time between more than one single thread (for the young ppl that never tried, without this everything goes wild :D)
1 alone is easy. 2 alone is easy. But combining 1, 2 and 3 isn't, because currently we could do 1) in Geany side, but 2 needs to call a TM function which wouldn't know about 3. What is needed then is to implement all in the TM side, and this needs quite a few changes not to access tm_file->tags during the update.
Well, that's just rough answer mostly take from my memory at trying to implement it once, maybe I missed some parts.
To conclude, yes it'd be good to have this at some point, but it's far from being trivial to implement, so it will need somebody to dig deep[2].
Regards, Colomban
[1] One could argue we should drop it in favor of custom code because TM is very hard to understand (to me), has a few annoying bugs and is overkill, but we do use it ATM… and nobody yet tried to get rid of it (lot of changes to do for probably only more bugs in the early times).
[2] and in the TM code, ouch :D
Am 07.11.2011 17:06, schrieb Colomban Wendling:
Hi,
Le 07/11/2011 16:35, Harold Aling a écrit :
Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
The "Generate tags for all project files" causes this massive delay, but I really need that feature.
At work I have a 2-core CPU, where 1 is completely idle and on my desktop at home there are 5 cores are doing nothing while generating tags. Can't they be utilized to speed up the tag generation?
TL;DR: it's really not that easy.
Might or might not be related. It's rather annoying how long geany takes to load files. Fine for single files, but a session of (say) 50 ones takes a while And the situation on my end hasn't improved by buying an SSD, so I don't think it's I/O related, so suspect tagmanager.
Best regards.
Best regards
On Mon, Nov 7, 2011 at 17:11, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 07.11.2011 17:06, schrieb Colomban Wendling:
Hi,
Le 07/11/2011 16:35, Harold Aling a écrit :
Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
The "Generate tags for all project files" causes this massive delay, but I really need that feature.
At work I have a 2-core CPU, where 1 is completely idle and on my desktop at home there are 5 cores are doing nothing while generating tags. Can't they be utilized to speed up the tag generation?
TL;DR: it's really not that easy.
What if the indexing is done as is, but on the background with an indicator in the statusbar?
-H-
On Tue, Nov 8, 2011 at 3:15 AM, Harold Aling geany@sait.nl wrote:
On Mon, Nov 7, 2011 at 17:11, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 07.11.2011 17:06, schrieb Colomban Wendling:
Hi,
Le 07/11/2011 16:35, Harold Aling a écrit :
Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
The "Generate tags for all project files" causes this massive delay, but I really need that feature.
At work I have a 2-core CPU, where 1 is completely idle and on my desktop at home there are 5 cores are doing nothing while generating tags. Can't they be utilized to speed up the tag generation?
TL;DR: it's really not that easy.
What if the indexing is done as is, but on the background with an indicator in the statusbar?
Hi,
As Colomban explained, tags cannot be accessed whilst tagmanager is updating them, that still has to be the case, so you can't use autocompletes and lots of other things whilst this is happening, and even if that was acceptable there would be lots of work to actually prevent the access.
Cheers Lex
-H- _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 11/07/2011 08:11 AM, Thomas Martitz wrote:
Am 07.11.2011 17:06, schrieb Colomban Wendling:
Hi,
Le 07/11/2011 16:35, Harold Aling a écrit :
Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
The "Generate tags for all project files" causes this massive delay, but I really need that feature.
At work I have a 2-core CPU, where 1 is completely idle and on my desktop at home there are 5 cores are doing nothing while generating tags. Can't they be utilized to speed up the tag generation?
TL;DR: it's really not that easy.
Might or might not be related. It's rather annoying how long geany takes to load files. Fine for single files, but a session of (say) 50 ones takes a while And the situation on my end hasn't improved by buying an SSD, so I don't think it's I/O related, so suspect tagmanager.
I suspect it's that TagManager, for every single tag, is inserting the tag into the tags array, removing duplicates, and then re-sorting the entire array.
The actual code/algos in use in TM is quite optimized, but I think the whole approach is flawed.
The best way IMO would be to use a lightweight DB like SQLite, where you can slam a bunch of data into it while it's in memory and then deal with sorting/searching during the queries later (or rather let the DB engine deal with them). IIUC, this would make threading much easier too, allowing one (or more) threads to be parsing and dumping tag info into the DB, while the UI is still running fine and seeing the new tags as they get inserted. You could also flush the DB to disk and use it as an index, so next run, much less work needs to be done over.
The chief benefit would of course be dropping all the TM code that no one really understands :)
Cheers, Matthew Brush
[...]
I suspect it's that TagManager, for every single tag, is inserting the tag into the tags array, removing duplicates, and then re-sorting the entire array.
All of the above prevent concurrent access :)
The actual code/algos in use in TM is quite optimized, but I think the whole approach is flawed.
The best way IMO would be to use a lightweight DB like SQLite, where you can slam a bunch of data into it while it's in memory and then deal with sorting/searching during the queries later (or rather let the DB engine deal with them). IIUC, this would make threading much easier too, allowing one (or more) threads to be parsing and dumping tag info into the DB, while the UI is still running fine and seeing the new tags as they get inserted. You could also flush the DB to disk and use it as an index, so next run, much less work needs to be done over.
Not so easy, from the sqlite faq:
(6) Is SQLite threadsafe?
Threads are evil. Avoid them.
And what they don't mention is that you can deadlock your system if the access isn't coordinated, ... back to square one.
The chief benefit would of course be dropping all the TM code that no one really understands :)
For another bunch noone really understands </optimist> :)
Cheers Lex
Am 08.11.2011 03:13, schrieb Lex Trotman:
Not so easy, from the sqlite faq:
(6) Is SQLite threadsafe?
Threads are evil. Avoid them.And what they don't mention is that you can deadlock your system if the access isn't coordinated, ... back to square one.
They do mention though that SQLite is thread-safe, and that a db connection can be shared across threads. So your quote draws things worse than they are.
Doesn't Anjuta use SQLite? Are they using it multi-threaded?
Best regards.
On Tue, Nov 8, 2011 at 7:49 PM, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 08.11.2011 03:13, schrieb Lex Trotman:
Not so easy, from the sqlite faq:
(6) Is SQLite threadsafe?
Threads are evil. Avoid them.
And what they don't mention is that you can deadlock your system if the access isn't coordinated, ... back to square one.
They do mention though that SQLite is thread-safe, and that a db connection can be shared across threads. So your quote draws things worse than they are.
True, the problem really is in how the threads access the d/b so they don't get in each other's way.
Doesn't Anjuta use SQLite? Are they using it multi-threaded?
I did suggest to Matthew on IRC that we steal Anjuta's code :)
Cheers Lex
On 11-11-08 12:49 AM, Thomas Martitz wrote:
Am 08.11.2011 03:13, schrieb Lex Trotman:
Not so easy, from the sqlite faq:
(6) Is SQLite threadsafe?
Threads are evil. Avoid them.
And what they don't mention is that you can deadlock your system if the access isn't coordinated, ... back to square one.
They do mention though that SQLite is thread-safe, and that a db connection can be shared across threads. So your quote draws things worse than they are.
Doesn't Anjuta use SQLite? Are they using it multi-threaded?
I think they use GTree while parsing and then dump to an sqlite database (via libgda). Judging by the _async() functions it has and the g_async_ stuff, it must be using threads in some fashion.
FWIW, here's the source: http://git.gnome.org/browse/anjuta/tree/plugins/symbol-db
Cheers, Matthew Brush
Am 08.11.2011 02:44, schrieb Matthew Brush:
I suspect it's that TagManager, for every single tag, is inserting the tag into the tags array, removing duplicates, and then re-sorting the entire array.
Is it possible to fix that part, i.e. sort/de-duplication after initial parsing (even if reading would be denied until that happened)?
Early geany+late tags is better than late geany+late tags, IMO.
Best regards.
On Tue, Nov 8, 2011 at 6:27 PM, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 08.11.2011 02:44, schrieb Matthew Brush:
I suspect it's that TagManager, for every single tag, is inserting the tag into the tags array, removing duplicates, and then re-sorting the entire array.
Is it possible to fix that part, i.e. sort/de-duplication after initial parsing (even if reading would be denied until that happened)?
I think tagmanager needs to be able to search as well as insert, so its a bit of a balancing act
Personally I would change it to use a balanced binary tree like GTree. That should give good search and reasonable insert capability. But no guarantees of performance improvement until it is done.
But someone has to brave the tagmanager code :)
Cheers Lex
Hi Harold,
On Mon, Nov 7, 2011 at 16:35, Harold Aling geany@sait.nl wrote:
Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
How much of this time is spent by opening the project and how much by closing? What time did the same take with granyprj? I think I have an explanation for longer project close times - geanyprj didn't properly remove the tags from the workspace and that's why the closing times were faster. If you don't mind that the tags aren't freed from the memory, you can comment-out lines 461 and 462 from gproject-project.c:
if (g_prj->generate_tags) g_hash_table_foreach(g_prj->file_tag_table, (GHFunc)workspace_remove_tag, NULL);
This should result in the same close times. If the open times are longer too with gproject, I'll have to investigate what's wrong.
Now the interesting part about the tag manager is that from some number of files, removing file tags from the workspace takes longer than adding them. Without properly studying tag manager sources, I think I know what the reason is: it looks as if the hierarchy of tags was connected by pointers in one direction only so it is easy to find a particular tag but when you have a tag and you want to find which tags refer to this tag, you have to go through all the tags to find references to the particular tag. This is what happens when you want to remove a tag from the workspace because you need to delete all references to this tag.
I have also experienced something like quadratic time complexity when generating tags for many files - the time needed to insert the tags definitely doesn't grow linearly with the number of files. This means that the problem isn't slow parsing of files by the ctags part of the tag manager but rather the creation of the hierarchy by the tag manager part.
This also means that parsing the files in parallel won't help - it's the tag hierarchy creation which is slow for high number of files. And finding some fine-grained locking so more threads can create the hierarchy in parallel is a complete overkill.
Having a good look at the tag manager, understanding the code and finding a way to avoid this quadratic time behavior (possibly by rewriting it completely) is something I'd really love to do (could be a lot of fun). The only problem is time right now (I might have more time in a few months but no promisses).
Cheers, Jiri
On Fri, Nov 11, 2011 at 22:13, Jiří Techet techet@gmail.com wrote:
Hi Harold,
On Mon, Nov 7, 2011 at 16:35, Harold Aling geany@sait.nl wrote:
Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
How much of this time is spent by opening the project and how much by closing?
Opening Geany takes 4 minutes with 2 Drupal projects active. :(
What time did the same take with granyprj?
Far less, but it's quite hectic here atm, so I can't do any comparisons...
Haven't forgot about this though!
-H-
Best whishes for all!!!
On Wed, Dec 7, 2011 at 13:39, Harold Aling geany@sait.nl wrote:
On Fri, Nov 11, 2011 at 22:13, Jiří Techet techet@gmail.com wrote:
Hi Harold,
On Mon, Nov 7, 2011 at 16:35, Harold Aling geany@sait.nl wrote:
Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
How much of this time is spent by opening the project and how much by closing?
Opening Geany takes 4 minutes with 2 Drupal projects active. :(
To start 2012 I decided to update my Geany and Geany-plugins installs to the latest dev, which caused my colorscheme[1] to display distorted. (white background except for the active line)
Restarting Geany takes more than 8 minutes so troubleshooting with my current configuration is quite the pain in the behind.
I'm going to give up on Gproject and either try GeanyPRJ again or ditch project support altogether. This simply doesn't work.
Cheers!
Harold
On Tue, Jan 3, 2012 at 9:00 PM, Harold Aling geany@sait.nl wrote:
Best whishes for all!!!
On Wed, Dec 7, 2011 at 13:39, Harold Aling geany@sait.nl wrote:
On Fri, Nov 11, 2011 at 22:13, Jiří Techet techet@gmail.com wrote:
Hi Harold,
On Mon, Nov 7, 2011 at 16:35, Harold Aling geany@sait.nl wrote:
Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
How much of this time is spent by opening the project and how much by closing?
Opening Geany takes 4 minutes with 2 Drupal projects active. :(
To start 2012 I decided to update my Geany and Geany-plugins installs to the latest dev, which caused my colorscheme[1] to display distorted. (white background except for the active line)
Hi Harold,
The latest development version of Geany has some changes in the way colour schemes work which means that some older themes may no longer work as they had. Unfortunately sometimes backward incompatible changes have to be made to continue moving forward.
Restarting Geany takes more than 8 minutes so troubleshooting with my current configuration is quite the pain in the behind.
You can use the -c option to create a new configuration directory and debug your colour schemes there. That way you can have no files and no tags during fixing but not lose your setup.
I'm going to give up on Gproject and either try GeanyPRJ again or ditch project support altogether. This simply doesn't work.
The standard Geany project support doesn't provide some of the nice features of these plugins, but it also doesn't tag parse your whole directory tree each startup, so performance should be ok.
Cheers Lex
Cheers!
Harold
[1] http://code.google.com/p/geany-dark-scheme/ _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am 03.01.2012 12:10, schrieb Lex Trotman:
I'm going to give up on Gproject and either try GeanyPRJ again or ditch project support altogether. This simply doesn't work.
The standard Geany project support doesn't provide some of the nice features of these plugins, but it also doesn't tag parse your whole directory tree each startup, so performance should be ok.
Both plugins (IIRC) offer a check box to disable tag generation.
Best regards.
On Tue, Jan 3, 2012 at 12:10, Lex Trotman elextr@gmail.com wrote:
On Tue, Jan 3, 2012 at 9:00 PM, Harold Aling geany@sait.nl wrote:
Best whishes for all!!!
On Wed, Dec 7, 2011 at 13:39, Harold Aling geany@sait.nl wrote:
On Fri, Nov 11, 2011 at 22:13, Jiří Techet techet@gmail.com wrote:
Hi Harold,
On Mon, Nov 7, 2011 at 16:35, Harold Aling geany@sait.nl wrote:
Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
How much of this time is spent by opening the project and how much by closing?
Opening Geany takes 4 minutes with 2 Drupal projects active. :(
To start 2012 I decided to update my Geany and Geany-plugins installs to the latest dev, which caused my colorscheme[1] to display distorted. (white background except for the active line)
Hi Harold,
The latest development version of Geany has some changes in the way colour schemes work which means that some older themes may no longer work as they had. Unfortunately sometimes backward incompatible changes have to be made to continue moving forward.
I understand the reason, but what I don't understand is how to "port" my old theme settings to the new system.
Copying filetypes.php to ~/.config/geany/filedefs and editing [styling] does not work and I can't seem to find any documentation on how to fix this. 'geany-dark-scheme' seems to be abandoned as the last release was in March 2010...
Any pointers on how I can re-enable my scheme for .php files?
Restarting Geany takes more than 8 minutes so troubleshooting with my current configuration is quite the pain in the behind.
You can use the -c option to create a new configuration directory and debug your colour schemes there. That way you can have no files and no tags during fixing but not lose your setup.
I already disabled project support, so I can restart Geany without having to fetch coffee for all my collegues ;)
I'm a big advocate on using Geany as editor here at work, but even Eclipse is faster and less resource-happy with tag generation. 4 minutes to open or close an application is not really acceptable for many users, including myself.
I'm going to give up on Gproject and either try GeanyPRJ again or ditch project support altogether. This simply doesn't work.
The standard Geany project support doesn't provide some of the nice features of these plugins, but it also doesn't tag parse your whole directory tree each startup, so performance should be ok.
Tag generation is the only reason I (have to) use a project plugin.
-H-
Hi Harold,
[...]
I understand the reason, but what I don't understand is how to "port" my old theme settings to the new system.
Copying filetypes.php to ~/.config/geany/filedefs and editing [styling] does not work and I can't seem to find any documentation on how to fix this. 'geany-dark-scheme' seems to be abandoned as the last release was in March 2010...
Any pointers on how I can re-enable my scheme for .php files?
Sorry I'm not a theme expert, maybe one of the experts can advise.
[...]
Tag generation is the only reason I (have to) use a project plugin.
Sounds like a rock and a hard place :)
Possibly the plugins or tags system itself could use some sort of cache so unchanged files didn't need re-parsing, just loading. That would "probably" be easier than trying to run tags in separate threads and so on, after all you still wouldn't have full functionality for 8 minutes until the tags are generated (probably longer due to the inevitable threading overheads).
Cheers Lex
On 01/03/2012 03:36 AM, Harold Aling wrote:
On Tue, Jan 3, 2012 at 12:10, Lex Trotmanelextr@gmail.com wrote:
On Tue, Jan 3, 2012 at 9:00 PM, Harold Alinggeany@sait.nl wrote:
Best whishes for all!!!
On Wed, Dec 7, 2011 at 13:39, Harold Alinggeany@sait.nl wrote:
On Fri, Nov 11, 2011 at 22:13, Jiří Techettechet@gmail.com wrote:
Hi Harold,
On Mon, Nov 7, 2011 at 16:35, Harold Alinggeany@sait.nl wrote:
Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
How much of this time is spent by opening the project and how much by closing?
Opening Geany takes 4 minutes with 2 Drupal projects active. :(
To start 2012 I decided to update my Geany and Geany-plugins installs to the latest dev, which caused my colorscheme[1] to display distorted. (white background except for the active line)
Hi Harold,
The latest development version of Geany has some changes in the way colour schemes work which means that some older themes may no longer work as they had. Unfortunately sometimes backward incompatible changes have to be made to continue moving forward.
I understand the reason, but what I don't understand is how to "port" my old theme settings to the new system.
I already ported all of the existing old-style color schemes to work with the new filedefs, see the geany-themes[1] project on Github to get them. Some might need a little tweaking, but should for the most part be quite similar to the original ones.
If you have other customizations in your old filedefs, you can copy them from the old file manually (there's not that many). What's more you'll benefit from the new features/fixes/keyword updates/etc introduced since you grabbed a version frozen in 2010.
This is actually one of the huge advantages of using color schemes; you don't have to replace all your filedefs to change styles any more (nor do you any longer need to change *every* filedef file to change themes or a color even). For the most part, you shouldn't even need to touch the filedefs with regards to color schemes, only the color scheme .conf files.
Copying filetypes.php to ~/.config/geany/filedefs and editing [styling] does not work and I can't seem to find any documentation on how to fix this. 'geany-dark-scheme' seems to be abandoned as the last release was in March 2010...
It is explained in the manual, though I'm sure it could be improved. If you open a colorscheme, open a filedef/filetypes.* file, and open the manual, you should be able to figure it out fairly quickly, it's just INI files after all.
Any pointers on how I can re-enable my scheme for .php files?
See above.
Restarting Geany takes more than 8 minutes so troubleshooting with my current configuration is quite the pain in the behind.
You can use the -c option to create a new configuration directory and debug your colour schemes there. That way you can have no files and no tags during fixing but not lose your setup.
I already disabled project support, so I can restart Geany without having to fetch coffee for all my collegues ;)
I'm a big advocate on using Geany as editor here at work, but even Eclipse is faster and less resource-happy with tag generation. 4 minutes to open or close an application is not really acceptable for many users, including myself.
That's not really Geany causing it to take that long, to be fair.
I'm going to give up on Gproject and either try GeanyPRJ again or ditch project support altogether. This simply doesn't work.
The standard Geany project support doesn't provide some of the nice features of these plugins, but it also doesn't tag parse your whole directory tree each startup, so performance should be ok.
Tag generation is the only reason I (have to) use a project plugin.
Cheers, Matthew Brush
On Fri, Nov 11, 2011 at 22:13, Jiří Techet techet@gmail.com wrote:
Hi Harold,
On Mon, Nov 7, 2011 at 16:35, Harold Aling geany@sait.nl wrote:
Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
How much of this time is spent by opening the project and how much by closing? What time did the same take with granyprj?
Just had a little time to check loading times with GeanyPRJ versus GProject.
Starting Geany with 1 file open in a Drupal project with GProject enabled: 4 minutes and 1 second. Starting Geany with the same file with GeanyPRJ enabled: 23 seconds.
Quitting Geany with an open Drupal project with GProject enabled: about 4 minutes. Quitting Geany with the same Drupal project with GeanyPRJ enabled: almost instant.
The second time I opened the project with GProject, it only took 3 minutes, so it has some caching benefits.
I'm reverting to GeanyPRJ! Too bad it causes a lag while typing, but that's way better than having to wait 4 minutes to start or quit Geany...
Cheers!
Harold
On Tue, 24 Jan 2012 11:35:40 +0100 Harold Aling geany@sait.nl wrote:
Just had a little time to check loading times with GeanyPRJ versus GProject.
Starting Geany with 1 file open in a Drupal project with GProject enabled: 4 minutes and 1 second. Starting Geany with the same file with GeanyPRJ enabled: 23 seconds.
Quitting Geany with an open Drupal project with GProject enabled: about 4 minutes. Quitting Geany with the same Drupal project with GeanyPRJ enabled: almost instant.
The second time I opened the project with GProject, it only took 3 minutes, so it has some caching benefits.
I'm reverting to GeanyPRJ! Too bad it causes a lag while typing, but that's way better than having to wait 4 minutes to start or quit Geany...
Am I really that weird? Granted I'm using geanie's built-in project support (More like managed sessions), but I see a worst case for my use of about 45 seconds to load a series of files.
But the thing is, my current "session" of geany has been open now for about 4 days. 4 minutes in that time frame is a drop in the ocean. How often do you open + close geany for a 4 minute start up to be more annoying than a continuous lag when typing?
Jon
On Tue, Jan 24, 2012 at 11:42, Jon Senior jon@restlesslemon.co.uk wrote:
On Tue, 24 Jan 2012 11:35:40 +0100 Harold Aling geany@sait.nl wrote:
Just had a little time to check loading times with GeanyPRJ versus GProject.
Starting Geany with 1 file open in a Drupal project with GProject enabled: 4 minutes and 1 second. Starting Geany with the same file with GeanyPRJ enabled: 23 seconds.
Quitting Geany with an open Drupal project with GProject enabled: about 4 minutes. Quitting Geany with the same Drupal project with GeanyPRJ enabled: almost instant.
The second time I opened the project with GProject, it only took 3 minutes, so it has some caching benefits.
I'm reverting to GeanyPRJ! Too bad it causes a lag while typing, but that's way better than having to wait 4 minutes to start or quit Geany...
Am I really that weird? Granted I'm using geanie's built-in project support (More like managed sessions), but I see a worst case for my use of about 45 seconds to load a series of files.
I've set GProject to index all files in the project to be able to use ''Go to tag definition" so it's the time to reindex all files and tags, not just opening them...
But the thing is, my current "session" of geany has been open now for about 4 days. 4 minutes in that time frame is a drop in the ocean. How often do you open + close geany for a 4 minute start up to be more annoying than a continuous lag when typing?
Well, I work on 1 to 4 Drupal projects per week and sometimes I have to bughunt on even more projects. Every switch will take 4 to 8 minutes, which is "not very relaxing", especially if a collegue is standing here at my desk...
I also like to shutdown my machine in the weekends to prevent me from logging in from home ;)
-H-
On Tue, Jan 24, 2012 at 9:56 PM, Harold Aling geany@sait.nl wrote:
On Tue, Jan 24, 2012 at 11:42, Jon Senior jon@restlesslemon.co.uk wrote:
On Tue, 24 Jan 2012 11:35:40 +0100 Harold Aling geany@sait.nl wrote:
Just had a little time to check loading times with GeanyPRJ versus GProject.
Starting Geany with 1 file open in a Drupal project with GProject enabled: 4 minutes and 1 second. Starting Geany with the same file with GeanyPRJ enabled: 23 seconds.
Quitting Geany with an open Drupal project with GProject enabled: about 4 minutes. Quitting Geany with the same Drupal project with GeanyPRJ enabled: almost instant.
The second time I opened the project with GProject, it only took 3 minutes, so it has some caching benefits.
I'm reverting to GeanyPRJ! Too bad it causes a lag while typing, but that's way better than having to wait 4 minutes to start or quit Geany...
Am I really that weird? Granted I'm using geanie's built-in project support (More like managed sessions), but I see a worst case for my use of about 45 seconds to load a series of files.
I've set GProject to index all files in the project to be able to use ''Go to tag definition" so it's the time to reindex all files and tags, not just opening them...
But the thing is, my current "session" of geany has been open now for about 4 days. 4 minutes in that time frame is a drop in the ocean. How often do you open + close geany for a 4 minute start up to be more annoying than a continuous lag when typing?
Well, I work on 1 to 4 Drupal projects per week and sometimes I have to bughunt on even more projects. Every switch will take 4 to 8 minutes, which is "not very relaxing", especially if a collegue is standing here at my desk...
I also like to shutdown my machine in the weekends to prevent me from logging in from home ;)
There's an idea, but since I work from home the machine is right there, stalking me...
What might be a better idea than re-generating 1000 files worth of symbols each time is to run offline tags file generation, hopefully loading those will be faster than re-parsing all the files. Maybe you can test it some time.
And Geany will correct any errors in symbols for the files you have open and have changed.
All we need to add is the ability to save this over the top of the old tags file when the source file is saved, so you continue to get right symbols with the file closed. This is something that will be much more likely to happen in the near future compared to threaded parsing, there are too many problems with data sharing with the GUI thread, as discussed several times on IRC in the past.
Depends how much faster loading tags files is to see if its worth it.
Cheers lex
-H- _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, Jan 24, 2012 at 12:17, Lex Trotman elextr@gmail.com wrote:
On Tue, Jan 24, 2012 at 9:56 PM, Harold Aling geany@sait.nl wrote:
On Tue, Jan 24, 2012 at 11:42, Jon Senior jon@restlesslemon.co.uk wrote:
On Tue, 24 Jan 2012 11:35:40 +0100 Harold Aling geany@sait.nl wrote:
Just had a little time to check loading times with GeanyPRJ versus GProject.
Starting Geany with 1 file open in a Drupal project with GProject enabled: 4 minutes and 1 second. Starting Geany with the same file with GeanyPRJ enabled: 23 seconds.
Quitting Geany with an open Drupal project with GProject enabled: about 4 minutes. Quitting Geany with the same Drupal project with GeanyPRJ enabled: almost instant.
The second time I opened the project with GProject, it only took 3 minutes, so it has some caching benefits.
I'm reverting to GeanyPRJ! Too bad it causes a lag while typing, but that's way better than having to wait 4 minutes to start or quit Geany...
Am I really that weird? Granted I'm using geanie's built-in project support (More like managed sessions), but I see a worst case for my use of about 45 seconds to load a series of files.
I've set GProject to index all files in the project to be able to use ''Go to tag definition" so it's the time to reindex all files and tags, not just opening them...
But the thing is, my current "session" of geany has been open now for about 4 days. 4 minutes in that time frame is a drop in the ocean. How often do you open + close geany for a 4 minute start up to be more annoying than a continuous lag when typing?
Well, I work on 1 to 4 Drupal projects per week and sometimes I have to bughunt on even more projects. Every switch will take 4 to 8 minutes, which is "not very relaxing", especially if a collegue is standing here at my desk...
I also like to shutdown my machine in the weekends to prevent me from logging in from home ;)
There's an idea, but since I work from home the machine is right there, stalking me...
What might be a better idea than re-generating 1000 files worth of symbols each time is to run offline tags file generation, hopefully loading those will be faster than re-parsing all the files. Maybe you can test it some time.
And Geany will correct any errors in symbols for the files you have open and have changed.
All we need to add is the ability to save this over the top of the old tags file when the source file is saved, so you continue to get right symbols with the file closed. This is something that will be much more likely to happen in the near future compared to threaded parsing, there are too many problems with data sharing with the GUI thread, as discussed several times on IRC in the past.
Depends how much faster loading tags files is to see if its worth it.
OK, there's a plugin called gctags which I've been using for almost two years now but haven't had time to polish it and make part of geany-plugins. I've uploaded the plugin here:
https://github.com/techee/geany-gctags
How it works: 1. You need to have ctags installed in your system 2. In project->properties you set the file patterns which should be scanned for tags 3. There's a new menu item Project->generate tags - it scans all the files satisfying the patterns and creates tags file with the same name as the project file but with the extension .tags 4. There's Project->Find tag menu item: it pops up a dialog where you can search for the tag (you can assign keybinding for this action). After hitting enter, all the tags which are found are printed to the Messages window. I use some space-based indentation so it's better to use monospace font for the Messages window. After clicking a tag, you get to the corresponding line/file. 5. Instead of (4) you can use the context menu which has two new entries - "Find tag definition" and "Find tag declaration" - these print the definition/declaration of the symbol under cursor immediately.
The plugin doesn't do any smart reloading of tags - you have to do it manually from the menu. However in practice this has never been a problem for me - for recently used files you can use Geany's search in open files. When you find the tags are off or cannot be found, you can regenerate them manually - this is extremely FAST compared to what Geany needs for "parsing" (parsing is in apostrophes because it's not the parsing which is slow - it's some crazyness in the tag manager).
I've been working on very large projects (2 millions LOC in C) and this has been working very well for me. I've always disabled the tag generation by Geany because it's way too slow for any bigger project.
Cheers, Jiri
[...]
OK, there's a plugin called gctags which I've been using for almost two years now but haven't had time to polish it and make part of geany-plugins. I've uploaded the plugin here:
https://github.com/techee/geany-gctags
How it works:
- You need to have ctags installed in your system
- In project->properties you set the file patterns which should be
scanned for tags 3. There's a new menu item Project->generate tags - it scans all the files satisfying the patterns and creates tags file with the same name as the project file but with the extension .tags 4. There's Project->Find tag menu item: it pops up a dialog where you can search for the tag (you can assign keybinding for this action). After hitting enter, all the tags which are found are printed to the Messages window. I use some space-based indentation so it's better to use monospace font for the Messages window. After clicking a tag, you get to the corresponding line/file. 5. Instead of (4) you can use the context menu which has two new entries - "Find tag definition" and "Find tag declaration" - these print the definition/declaration of the symbol under cursor immediately.
Good one, does navigation, now all we need to add is completion :)
The plugin doesn't do any smart reloading of tags - you have to do it manually from the menu. However in practice this has never been a problem for me -
And after all, this is how ctags has worked in editors since emacs was a teco macro and vim was a vi in short pants.
for recently used files you can use Geany's search in open files. When you find the tags are off or cannot be found, you can regenerate them manually - this is extremely FAST compared to what Geany needs for "parsing" (parsing is in apostrophes because it's not the parsing which is slow - it's some crazyness in the tag manager).
Yeah, sadly that makes my suggestion of saving the tags unlikely to save much time, though I havn't tested it, anecdotally loading large saved tags files is still slow.
I've been working on very large projects (2 millions LOC in C) and this has been working very well for me. I've always disabled the tag generation by Geany because it's way too slow for any bigger project.
Lets encourage and help Colomban with his experiments of replacing tagmangler, and add ctags loading.
Cheers Lex
Cheers, Jiri _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Small update as I just dist-upgraded to the latest Xubuntu and recompiled Geany and Geany-plugins from git.
Opening Geany now takes 8 minutes and 41 seconds.
15:30:02: This is Geany 1.22 (git >= 249f9bc). 15:38:43: Project "Q7" opened.
-H-
On 2 May 2012 23:42, Harold Aling geany@sait.nl wrote:
Small update as I just dist-upgraded to the latest Xubuntu and recompiled Geany and Geany-plugins from git.
Opening Geany now takes 8 minutes and 41 seconds.
15:30:02: This is Geany 1.22 (git >= 249f9bc). 15:38:43: Project "Q7" opened.
Under what circumstances?
And you never answered Jiri's request in January for information to allow him to reproduce the problem.
Cheers Lex
-H- _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, Jan 24, 2012 at 11:35, Harold Aling geany@sait.nl wrote:
On Fri, Nov 11, 2011 at 22:13, Jiří Techet techet@gmail.com wrote:
Hi Harold,
On Mon, Nov 7, 2011 at 16:35, Harold Aling geany@sait.nl wrote:
Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
How much of this time is spent by opening the project and how much by closing? What time did the same take with granyprj?
Just had a little time to check loading times with GeanyPRJ versus GProject.
Starting Geany with 1 file open in a Drupal project with GProject enabled: 4 minutes and 1 second. Starting Geany with the same file with GeanyPRJ enabled: 23 seconds.
Quitting Geany with an open Drupal project with GProject enabled: about 4 minutes. Quitting Geany with the same Drupal project with GeanyPRJ enabled: almost instant.
The second time I opened the project with GProject, it only took 3 minutes, so it has some caching benefits.
This is really strange - I call the same tag-generation-related functions as GeanyPrj does so there shouldn't be any difference. Are you sure that there are the same patterns for both projects and that e.g. GProject doesn't match more files? That would explain the time, otherwise I have no explanation.
Is there any way I could reproduce it here? If you find some test case with e.g. some open source project I could download and test the tag generation time, I'm sure I can get to the same times as GeanyPrj - there's no reason why GProject should be slower.
Cheers, Jiri
Is there any way I could reproduce it here? If you find some test case with e.g. some open source project I could download and test the tag generation time, I'm sure I can get to the same times as GeanyPrj - there's no reason why GProject should be slower.
Jiri,
I seem to have missed this request ;)
I just tried to reproduce my enormous load-times by starting with an empty Drupal 7 download and adding modules and current subsites/projects. With every extra site I copied, Geany/Gprojects takes exponentially long to open until we reach the 8 minute mark again.
I work on several projects each week but I'll guess I have to delete as much files as possible to be able to start/close Geany within a couple of minutes, which still seems rather long for my 1-year-old desktop.
-H-
On 07/11/2011 15:35, Harold Aling wrote:
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
The "Generate tags for all project files" causes this massive delay, but I really need that feature.
At work I have a 2-core CPU, where 1 is completely idle and on my desktop at home there are 5 cores are doing nothing while generating tags. Can't they be utilized to speed up the tag generation?
As a workaround I wonder if the plugin could generate a temporary global tags file (with geany -g). This would be a separate thread. Then tell Geany to load the tags file - this is faster in Geany Git as it avoids resorting all global tags. We would need to add a way to remove global tags though, but this is probably straightforward.
Nick
On Mon, May 7, 2012 at 7:09 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 07/11/2011 15:35, Harold Aling wrote:
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't support multiple open projects I have to switch between projects, but it takes up to 4 minutes to close one project and open another. A project consists of roughly 1000-2000 php-related files.
The "Generate tags for all project files" causes this massive delay, but I really need that feature.
At work I have a 2-core CPU, where 1 is completely idle and on my desktop at home there are 5 cores are doing nothing while generating tags. Can't they be utilized to speed up the tag generation?
As a workaround I wonder if the plugin could generate a temporary global tags file (with geany -g). This would be a separate thread. Then tell Geany to load the tags file - this is faster in Geany Git as it avoids resorting all global tags. We would need to add a way to remove global tags though, but this is probably straightforward.
Nick
I just tried another workaround: I moved all my multisite projects into ~/checkout and only made symlinks for all projects I'm currently working on to prevent huge codebases. Just like sites-available and sites-enabled in Apache configuration ...
$ cat /var/www/drupal7/D7.geany | grep base_path base_path=/var/www/drupal7
$ ls -la /var/www/drupal7/sites/ | grep example lrwxrwxrwx 1 harold harold 27 Jul 2 15:34 example -> /home/harold/checkout/example
... only to discover that GProject doesn't follow symlinks :(
-H-