Dear devs,
Just pressing and holding a key pauses every ~10 characters. This is only the case in a document when working on a pre-existing file, a new document is as fast as can be.
What could be causing this? Does anybody else have the same problem? I'm working on a php/Drupal project and use the geanyprj plugin to index all files.
Harold
I removed all file paths from the dedug messages as it contains the name of our client and the project...
11:06:33: Geany INFO : Geany 0.21 (svn >= r5584), en_US.UTF-8 11:06:33: Geany INFO : GTK 2.22.0, GLib 2.26.1, GIO 11:06:33: Geany INFO : System data dir: /usr/local/share/geany 11:06:33: Geany INFO : User config dir: /home/harold/.config/geany 11:06:34: Geany INFO : Added filetype Genie (52). 11:06:34: Geany INFO : Added filetype Scala (53). 11:06:34: Geany INFO : Loaded: /usr/local/lib/geany/addons.so (Addons) 11:06:34: Geany INFO : Loaded: /usr/local/lib/geany/filebrowser.so (File Browser) 11:06:34: Geany INFO : Loaded: /usr/local/lib/geany/geanylipsum.so (GeanyLipsum) 11:06:34: Geany INFO : Loaded: /usr/local/lib/geany/geanyprj.so (Project) 11:06:34: Geany INFO : Plugin "/usr/lib/geany/filebrowser.so" already loaded. 11:06:34: Geany INFO : Plugin "/usr/lib/geany/geanyprj.so" already loaded. 11:06:34: Geany INFO : <document path>.css : CSS (UTF-8) 11:06:34: Geany INFO : Bad color '0x0' 11:06:34: Geany INFO : Bad color '0x0' 11:06:54: Geany INFO : <document path>.php : PHP (UTF-8) 11:06:54: Geany INFO : Loaded /usr/local/share/geany/php.tags (PHP), 2338 tag(s). 11:06:54: Geany INFO : Bad color '0xfffffff' 11:06:54: Geany INFO : <document path>.php : PHP (UTF-8) 11:06:54: Geany INFO : <document path>.php : PHP (UTF-8) 11:06:55: Geany INFO : <document path>.php : PHP (UTF-8) 11:06:55: Geany INFO : <document path>.css : CSS (UTF-8) 11:06:56: Geany INFO : <document path>.php : PHP (UTF-8) 11:06:56: Geany INFO : <document path>.php : PHP (UTF-8) 11:06:57: Geany INFO : <document path>.module : PHP (UTF-8) 11:06:57: Geany INFO : <document path>.info : None (UTF-8) 11:07:03: Geany INFO : <document path>.css : CSS (UTF-8) 11:07:34: Geany INFO : <document path>.css : CSS (UTF-8) 11:08:05: Geany INFO : <document path>.php : PHP (UTF-8) 11:08:19: Geany INFO : <document path>.php : PHP (UTF-8) 11:08:30: Geany INFO : <document path>.php : PHP (UTF-8) 11:08:55: Geany INFO : unknown : None (UTF-8) 11:09:22: Geany INFO : <document path>.php : PHP (UTF-8) 11:12:15: Geany INFO : unknown : None (UTF-8) 11:12:26: Geany INFO : unknown : PHP (UTF-8) 11:12:57: Geany INFO : <document path>.php : PHP (UTF-8) 11:13:51: Geany INFO : <document path>.php : PHP (UTF-8) 11:14:56: Geany INFO : <document path>.php : PHP (UTF-8)
On 23 March 2011 21:24, Harold Aling geany@sait.nl wrote:
Dear devs,
Just pressing and holding a key pauses every ~10 characters. This is only the case in a document when working on a pre-existing file, a new document is as fast as can be.
What could be causing this? Does anybody else have the same problem? I'm working on a php/Drupal project and use the geanyprj plugin to index all files.
Harold
Version? Platform? How big are the files? Are you editing near the beginning or the end? How fast is your computer and how much free memory does it have?
Cheers Lex
I removed all file paths from the dedug messages as it contains the name of our client and the project...
11:06:33: Geany INFO : Geany 0.21 (svn >= r5584), en_US.UTF-8 11:06:33: Geany INFO : GTK 2.22.0, GLib 2.26.1, GIO 11:06:33: Geany INFO : System data dir: /usr/local/share/geany 11:06:33: Geany INFO : User config dir: /home/harold/.config/geany 11:06:34: Geany INFO : Added filetype Genie (52). 11:06:34: Geany INFO : Added filetype Scala (53). 11:06:34: Geany INFO : Loaded: /usr/local/lib/geany/addons.so (Addons) 11:06:34: Geany INFO : Loaded: /usr/local/lib/geany/filebrowser.so (File Browser) 11:06:34: Geany INFO : Loaded: /usr/local/lib/geany/geanylipsum.so (GeanyLipsum) 11:06:34: Geany INFO : Loaded: /usr/local/lib/geany/geanyprj.so (Project) 11:06:34: Geany INFO : Plugin "/usr/lib/geany/filebrowser.so" already loaded. 11:06:34: Geany INFO : Plugin "/usr/lib/geany/geanyprj.so" already loaded. 11:06:34: Geany INFO : <document path>.css : CSS (UTF-8) 11:06:34: Geany INFO : Bad color '0x0' 11:06:34: Geany INFO : Bad color '0x0' 11:06:54: Geany INFO : <document path>.php : PHP (UTF-8) 11:06:54: Geany INFO : Loaded /usr/local/share/geany/php.tags (PHP), 2338 tag(s). 11:06:54: Geany INFO : Bad color '0xfffffff' 11:06:54: Geany INFO : <document path>.php : PHP (UTF-8) 11:06:54: Geany INFO : <document path>.php : PHP (UTF-8) 11:06:55: Geany INFO : <document path>.php : PHP (UTF-8) 11:06:55: Geany INFO : <document path>.css : CSS (UTF-8) 11:06:56: Geany INFO : <document path>.php : PHP (UTF-8) 11:06:56: Geany INFO : <document path>.php : PHP (UTF-8) 11:06:57: Geany INFO : <document path>.module : PHP (UTF-8) 11:06:57: Geany INFO : <document path>.info : None (UTF-8) 11:07:03: Geany INFO : <document path>.css : CSS (UTF-8) 11:07:34: Geany INFO : <document path>.css : CSS (UTF-8) 11:08:05: Geany INFO : <document path>.php : PHP (UTF-8) 11:08:19: Geany INFO : <document path>.php : PHP (UTF-8) 11:08:30: Geany INFO : <document path>.php : PHP (UTF-8) 11:08:55: Geany INFO : unknown : None (UTF-8) 11:09:22: Geany INFO : <document path>.php : PHP (UTF-8) 11:12:15: Geany INFO : unknown : None (UTF-8) 11:12:26: Geany INFO : unknown : PHP (UTF-8) 11:12:57: Geany INFO : <document path>.php : PHP (UTF-8) 11:13:51: Geany INFO : <document path>.php : PHP (UTF-8) 11:14:56: Geany INFO : <document path>.php : PHP (UTF-8) _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, Mar 23, 2011 at 12:07, Lex Trotman elextr@gmail.com wrote:
On 23 March 2011 21:24, Harold Aling geany@sait.nl wrote:
Dear devs,
Just pressing and holding a key pauses every ~10 characters. This is only the case in a document when working on a pre-existing file, a new document is as fast as can be.
What could be causing this? Does anybody else have the same problem? I'm working on a php/Drupal project and use the geanyprj plugin to index all files.
Harold
I disabled the geanyprj plugin and the performance is back! Unfortunately, geanyprj is one of my reasons for using Geany. :(
Version?
11:06:33: Geany INFO : Geany 0.21 (svn >= r5584), en_US.UTF-8
Platform?
11:06:33: Geany INFO : GTK 2.22.0, GLib 2.26.1, GIO Ubuntu 10.10 (LXDE; 64 bits)
How big are the files?
Some are 100 lines long, some are 4k lines long.
Are you editing near the beginning or the end?
Everywhere
How fast is your computer and how much free memory does it have?
AMD Athlon(tm) II X2 250 Processor (Dual core; 3.0 GHz) 4 GiB memory; ~2 GiB available(/cache)
-H-
On 23 March 2011 22:26, Harold Aling geany@sait.nl wrote:
On Wed, Mar 23, 2011 at 12:07, Lex Trotman elextr@gmail.com wrote:
On 23 March 2011 21:24, Harold Aling geany@sait.nl wrote:
Dear devs,
Just pressing and holding a key pauses every ~10 characters. This is only the case in a document when working on a pre-existing file, a new document is as fast as can be.
What could be causing this? Does anybody else have the same problem? I'm working on a php/Drupal project and use the geanyprj plugin to index all files.
Harold
I disabled the geanyprj plugin and the performance is back! Unfortunately, geanyprj is one of my reasons for using Geany. :(
Important information.
Well since the machine you describe is just barely suitable for editing 100 line files :-D
I would suggest that there may be an interaction between real-time tag parsing that was recently added to the SVN version and Geanyprj that makes heavy use of tags.
Unfortunately there doesn't seem to be any documentation on real-time parsing or any way to turn it off to see if thats the case.
Cheers Lex
Version?
11:06:33: Geany INFO : Geany 0.21 (svn >= r5584), en_US.UTF-8
Platform?
11:06:33: Geany INFO : GTK 2.22.0, GLib 2.26.1, GIO Ubuntu 10.10 (LXDE; 64 bits)
How big are the files?
Some are 100 lines long, some are 4k lines long.
Are you editing near the beginning or the end?
Everywhere
How fast is your computer and how much free memory does it have?
AMD Athlon(tm) II X2 250 Processor (Dual core; 3.0 GHz) 4 GiB memory; ~2 GiB available(/cache)
-H-
Am 23.03.2011 13:22, schrieb Lex Trotman:
I would suggest that there may be an interaction between real-time tag parsing that was recently added to the SVN version and Geanyprj that makes heavy use of tags.
Unfortunately there doesn't seem to be any documentation on real-time parsing or any way to turn it off to see if thats the case.
There is some tooltip info. Turn it to 0 inside preferences and it should be normal tag parsing as we had before.
(I saw this during doing some translation work for German translation... ;) )
Cheers, Frank
On 23 March 2011 23:32, Frank Lanitz frank@frank.uvena.de wrote:
Am 23.03.2011 13:22, schrieb Lex Trotman:
I would suggest that there may be an interaction between real-time tag parsing that was recently added to the SVN version and Geanyprj that makes heavy use of tags.
Unfortunately there doesn't seem to be any documentation on real-time parsing or any way to turn it off to see if thats the case.
There is some tooltip info. Turn it to 0 inside preferences and it should be normal tag parsing as we had before.
By reading the code I think you mean editor preferences, completions tab, symbol list update frequency set to zero.
For the writer of the real-time tags, preferences documentation needs fixing and probably a good idea to say something in the tags section too.
Cheers Lex
(I saw this during doing some translation work for German translation... ;) )
Cheers, Frank _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am 23.03.2011 13:36, schrieb Lex Trotman:
On 23 March 2011 23:32, Frank Lanitz frank@frank.uvena.de wrote:
Am 23.03.2011 13:22, schrieb Lex Trotman:
I would suggest that there may be an interaction between real-time tag parsing that was recently added to the SVN version and Geanyprj that makes heavy use of tags.
Unfortunately there doesn't seem to be any documentation on real-time parsing or any way to turn it off to see if thats the case.
There is some tooltip info. Turn it to 0 inside preferences and it should be normal tag parsing as we had before.
By reading the code I think you mean editor preferences, completions tab, symbol list update frequency set to zero.
Yepp. Something like this. I just did remember the strings for this ;)
For the writer of the real-time tags, preferences documentation needs fixing and probably a good idea to say something in the tags section too.
I agree.
Cheers, Frank
On Wed, Mar 23, 2011 at 13:36, Lex Trotman elextr@gmail.com wrote:
On 23 March 2011 23:32, Frank Lanitz frank@frank.uvena.de wrote:
Am 23.03.2011 13:22, schrieb Lex Trotman:
I would suggest that there may be an interaction between real-time tag parsing that was recently added to the SVN version and Geanyprj that makes heavy use of tags.
Unfortunately there doesn't seem to be any documentation on real-time parsing or any way to turn it off to see if thats the case.
There is some tooltip info. Turn it to 0 inside preferences and it should be normal tag parsing as we had before.
By reading the code I think you mean editor preferences, completions tab, symbol list update frequency set to zero.
Yup, that fixed the lag! But it also diabled the real-time parser, which was a welcome addition.
Can this be fixed somehow?
-H-
By reading the code I think you mean editor preferences, completions tab, symbol list update frequency set to zero.
Yup, that fixed the lag! But it also diabled the real-time parser, which was a welcome addition.
Can this be fixed somehow?
Thats a bit harder, probably Yura, the plugin writer will need to take a look at the problem I'd say.
Cheers Lex
-H-
On Wed, Mar 23, 2011 at 13:49, Lex Trotman elextr@gmail.com wrote:
By reading the code I think you mean editor preferences, completions tab, symbol list update frequency set to zero.
Yup, that fixed the lag! But it also diabled the real-time parser, which was a welcome addition.
Can this be fixed somehow?
Thats a bit harder, probably Yura, the plugin writer will need to take a look at the problem I'd say.
Could it be that the real-time parser reparses all files in the project instead of just the current file?
In the mean time, I'll just disable the real time parsing.
-H-
On 23 March 2011 23:49, Lex Trotman elextr@gmail.com wrote:
By reading the code I think you mean editor preferences, completions tab, symbol list update frequency set to zero.
Yup, that fixed the lag! But it also diabled the real-time parser, which was a welcome addition.
Can this be fixed somehow?
Thats a bit harder, probably Yura, the plugin writer will need to take a look at the problem I'd say.
I forgot to say you probably should notify him, see the plugin web page.
Cheers Lex
Cheers Lex
-H-
On Wed, Mar 23, 2011 at 13:53, Lex Trotman elextr@gmail.com wrote:
Thats a bit harder, probably Yura, the plugin writer will need to take a look at the problem I'd say.
I forgot to say you probably should notify him, see the plugin web page.
Done!
-H-
Hi,
Le 23/03/2011 13:53, Harold Aling a écrit :
On Wed, Mar 23, 2011 at 13:49, Lex Trotman elextr@gmail.com wrote:
By reading the code I think you mean editor preferences, completions tab, symbol list update frequency set to zero.
Yup, that fixed the lag! But it also diabled the real-time parser, which was a welcome addition.
Can this be fixed somehow?
Thats a bit harder, probably Yura, the plugin writer will need to take a look at the problem I'd say.
Could it be that the real-time parser reparses all files in the project instead of just the current file?
No, it doesn't (or then it's a very strange bug I have to fix...).
In the mean time, I'll just disable the real time parsing.
You can try increasing the minimal delay between two updates to reduce the lag (the very preference you set to 0). Doing so will reduce the "realtimeness" of the tag parsing, but should improve the performances. Maybe the default delay of 250ms should be changed to a longer one, 250 being too aggressive...
Regards, Colomban
Le 23/03/2011 13:36, Lex Trotman a écrit :
On 23 March 2011 23:32, Frank Lanitz frank@frank.uvena.de wrote:
Unfortunately there doesn't seem to be any documentation on real-time parsing or any way to turn it off to see if thats the case.
There is some tooltip info. Turn it to 0 inside preferences and it should be normal tag parsing as we had before.
By reading the code I think you mean editor preferences, completions tab, symbol list update frequency set to zero.
For the writer of the real-time tags, preferences documentation needs fixing and probably a good idea to say something in the tags section too.
True, will try to fix this ASAP, thanks for pointing it out.
Cheers, Colomban
On Wed, Mar 23, 2011 at 14:12, Colomban Wendling lists.ban@herbesfolles.org wrote:
In the mean time, I'll just disable the real time parsing.
You can try increasing the minimal delay between two updates to reduce the lag (the very preference you set to 0). Doing so will reduce the "realtimeness" of the tag parsing, but should improve the performances. Maybe the default delay of 250ms should be changed to a longer one, 250 being too aggressive...
Even when not triggered that often, the lag is really annoying... Reminds me of the Eclipse editor an ex-collegue of mine used: the ultimate test for blind typing! Eclipse was always one word behind... ;)
I use geany for it's speed and simplicity, a lag doesn't fit in that description.
-H-
Thats a bit harder, probably Yura, the plugin writer will need to take a look at the problem I'd say.
Could it be that the real-time parser reparses all files in the project instead of just the current file?
No, it doesn't (or then it's a very strange bug I have to fix...).
Since performance is ok with real-time parsing but without Geanyprj and without real-time parsing but with Geanyprj the problem must be some kind of interaction. Does updating the tags do something that triggers Geanyprj in some way (eg document activation signal) which then causes more work to be done?
In the mean time, I'll just disable the real time parsing.
You can try increasing the minimal delay between two updates to reduce the lag (the very preference you set to 0). Doing so will reduce the "realtimeness" of the tag parsing, but should improve the performances. Maybe the default delay of 250ms should be changed to a longer one, 250 being too aggressive...
Havn't used it much so far, but works ok for me at 250. The updates are just visible, but its not too far from the 100ms thats usually taken as the lower limit of noticing UI delays so I think its a reasonable compromise.
Cheers Lex
Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Even when not triggered that often, the lag is really annoying... Reminds me of the Eclipse editor an ex-collegue of mine used: the ultimate test for blind typing! Eclipse was always one word behind... ;)
Its very mean saying Geany is like Eclipse [tantrum] :-(
I use geany for it's speed and simplicity, a lag doesn't fit in that description.
Sigh, plugin systems are great because they allow anyone to add functionality that they want. Sigh, plugin systems are a problem because they allow anyone to add functionality any way they want. :-)
The Geany team doesn't have the resources to manage all the plugins and ensure that they fit the philosophy or how well they are implemented and maintained. But Geany still gets the blame :-(
Cheers Lex
-H- _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, Mar 23, 2011 at 14:50, Lex Trotman elextr@gmail.com wrote:
Even when not triggered that often, the lag is really annoying... Reminds me of the Eclipse editor an ex-collegue of mine used: the ultimate test for blind typing! Eclipse was always one word behind... ;)
Its very mean saying Geany is like Eclipse [tantrum] :-(
I didn't say that! I said the lag introduced by geanyprj reminded me of a laggy Eclipse which was really slow on it's own, even without the "aid" of a plugin ;)
I use geany for it's speed and simplicity, a lag doesn't fit in that description.
Sigh, plugin systems are great because they allow anyone to add functionality that they want. Sigh, plugin systems are a problem because they allow anyone to add functionality any way they want. :-)
The Geany team doesn't have the resources to manage all the plugins and ensure that they fit the philosophy or how well they are implemented and maintained. But Geany still gets the blame :-(
That is indeed the downside of plugins, but I can't imagine Geany without it.
-H-
Le 23/03/2011 14:14, Colomban Wendling a écrit :
Le 23/03/2011 13:36, Lex Trotman a écrit :
On 23 March 2011 23:32, Frank Lanitz frank@frank.uvena.de wrote:
Unfortunately there doesn't seem to be any documentation on real-time parsing or any way to turn it off to see if thats the case.
There is some tooltip info. Turn it to 0 inside preferences and it should be normal tag parsing as we had before.
By reading the code I think you mean editor preferences, completions tab, symbol list update frequency set to zero.
For the writer of the real-time tags, preferences documentation needs fixing and probably a good idea to say something in the tags section too.
True, will try to fix this ASAP, thanks for pointing it out.
Done. However, I'm not a really good writer of this kind of documentation... any comments and/or improvements are welcome :)
Regards, Colomban
Le 23/03/2011 14:25, Lex Trotman a écrit :
Thats a bit harder, probably Yura, the plugin writer will need to take a look at the problem I'd say.
Could it be that the real-time parser reparses all files in the project instead of just the current file?
No, it doesn't (or then it's a very strange bug I have to fix...).
Since performance is ok with real-time parsing but without Geanyprj and without real-time parsing but with Geanyprj the problem must be some kind of interaction. Does updating the tags do something that triggers Geanyprj in some way (eg document activation signal) which then causes more work to be done?
I don't think so (no 100% sure, but almost). Maybe Geanyprj does something every <time> seconds, and does more work if tags have changed? (easy enough ti check I guess) ...don't know. A talk with Yura to figure out from where the lag comes would be useful I think :)
In the mean time, I'll just disable the real time parsing.
You can try increasing the minimal delay between two updates to reduce the lag (the very preference you set to 0). Doing so will reduce the "realtimeness" of the tag parsing, but should improve the performances. Maybe the default delay of 250ms should be changed to a longer one, 250 being too aggressive...
Havn't used it much so far, but works ok for me at 250. The updates are just visible, but its not too far from the 100ms thats usually taken as the lower limit of noticing UI delays so I think its a reasonable compromise.
Actually I set 250ms quite arbitrary after the performances on my computer. Something like "100ms is OK for me, let's add a x1.5 factor for older machines not to lag... OK, 250ms looks good" :D
Cheers, Colomban
Done. However, I'm not a really good writer of this kind of documentation... any comments and/or improvements are welcome :)
Couple of minor comments (I've used lines from the Geany.txt diff to identify them, hence the + signs.):
+Tags for each document are parsed whenever a file is loaded or saved, and
Just replace the "or" with a comma.
+possibly when modified (see *Symbol list update frequency* preference in the
Since the default is to update on modify, I'd leave the "possibly" out.
+ current document. The smaller is the delay the more up-to-date is the + symbol list (and then the completions); but rebuilding the symbol list + has a cost in performance, especially with large files.
Leave out both "is" in the preceding sentence, not needed, add a comma after delay.
+ + The default value is 250, which means the symbol list will be updated at
Add milliseconds after 250
+ most 4 times per second, even if the document changes continuously.
Single digits should be spelled out so "four".
Cheers Lex
On 24 March 2011 10:28, Lex Trotman elextr@gmail.com wrote:
Done. However, I'm not a really good writer of this kind of documentation... any comments and/or improvements are welcome :)
Also just realised that the image needs to be updated to show the new field.
Cheers Lex
Le 24/03/2011 00:28, Lex Trotman a écrit :
Done. However, I'm not a really good writer of this kind of documentation... any comments and/or improvements are welcome :)
Couple of minor comments (I've used lines from the Geany.txt diff to identify them, hence the + signs.):
+Tags for each document are parsed whenever a file is loaded or saved, and
Just replace the "or" with a comma.
+possibly when modified (see *Symbol list update frequency* preference in the
Since the default is to update on modify, I'd leave the "possibly" out.
- current document. The smaller is the delay the more up-to-date is the
- symbol list (and then the completions); but rebuilding the symbol list
- has a cost in performance, especially with large files.
Leave out both "is" in the preceding sentence, not needed, add a comma after delay.
- The default value is 250, which means the symbol list will be updated at
Add milliseconds after 250
- most 4 times per second, even if the document changes continuously.
Single digits should be spelled out so "four".
Thanks! Should be fixed now, tell me if there still are some :)
Cheers, Colomban
Le 24/03/2011 01:57, Lex Trotman a écrit :
On 24 March 2011 10:28, Lex Trotman elextr@gmail.com wrote:
Done. However, I'm not a really good writer of this kind of documentation... any comments and/or improvements are welcome :)
Also just realised that the image needs to be updated to show the new field.
Right, I've seen it too. Gotta ping Enrico if he can update it, to get the same GTK+ scheme and stuff.
On Wed, 23 Mar 2011 23:49:41 +1100 Lex Trotman elextr@gmail.com wrote:
Thats a bit harder, probably Yura, the plugin writer will need to take a look at the problem I'd say.
I looked at the problem:
1) geanyprj act only on "document-open", "document-save", "document-activate" callbacks 2) geanyprj add a lot of TMWorkObject objects using tm_workspace_add_object() to Geany 3) Geany call update_tags_from_buffer() very often.
I think this function somehow reparse a lot of objects because of "update_parent" param. I am not sure what this param actualy mean but if I change function this way performance is back to normal (I don't say we need to change it, it is just research):
--- a/src/document.c +++ b/src/document.c @@ -2263,7 +2263,7 @@ static gboolean update_tags_from_buffer(GeanyDocument *doc) /* we copy the whole text into memory instead using a direct char pointer from * Scintilla because tm_source_file_buffer_update() does modify the string slightly */ sci_get_text(doc->editor->sci, len, text); - result = tm_source_file_buffer_update(doc->tm_file, (guchar*) text, len, TRUE); + result = tm_source_file_buffer_update(doc->tm_file, (guchar*) text, len, FALSE); g_free(text); #endif return result;
On 27 March 2011 12:31, Yura Siamashka yurand2@gmail.com wrote:
On Wed, 23 Mar 2011 23:49:41 +1100 Lex Trotman elextr@gmail.com wrote:
Thats a bit harder, probably Yura, the plugin writer will need to take a look at the problem I'd say.
I looked at the problem:
- geanyprj act only on "document-open", "document-save", "document-activate" callbacks
- geanyprj add a lot of TMWorkObject objects using tm_workspace_add_object() to Geany
And tm_workspace_add_object sets the parent to be the whole workspace!
- Geany call update_tags_from_buffer() very often.
I think this function somehow reparse a lot of objects because of "update_parent" param. I am not sure what this param actualy mean but if I change function this way performance is back to normal (I don't say we need to change it, it is just research):
--- a/src/document.c +++ b/src/document.c @@ -2263,7 +2263,7 @@ static gboolean update_tags_from_buffer(GeanyDocument *doc) /* we copy the whole text into memory instead using a direct char pointer from * Scintilla because tm_source_file_buffer_update() does modify the string slightly */ sci_get_text(doc->editor->sci, len, text);
- result = tm_source_file_buffer_update(doc->tm_file, (guchar*) text, len, TRUE);
Because of item 2) above I think this will reparse all open files.
The question is can problems be introduced by not reparsing things, eg if we are editing a .h file, can that affect the symbols of the .c files that include it ... probably possible AFAICT.
Is there some easy way of triggering re-parsing of dependencies when the sidebar is about to swap to a different file? That way real-time update only needs to do the one file being edited, but no artifacts are introduced due to inconsistencies between when tags were parsed.
Cheers Lex
- result = tm_source_file_buffer_update(doc->tm_file, (guchar*) text, len, FALSE);
g_free(text); #endif return result;
-- Yura Siamashka yurand2@gmail.com _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 27.03.2011 05:15, Lex Trotman wrote:
The question is can problems be introduced by not reparsing things, eg if we are editing a .h file, can that affect the symbols of the .c files that include it ... probably possible AFAICT.
Is there some easy way of triggering re-parsing of dependencies when the sidebar is about to swap to a different file? That way real-time update only needs to do the one file being edited, but no artifacts are introduced due to inconsistencies between when tags were parsed.
Cheers Lex
Is the tag parsing even dependency aware? I thought it simply collects tags from all open files (and pre-loaded tag files).
Best regards.
On 28 March 2011 12:35, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
On 27.03.2011 05:15, Lex Trotman wrote:
The question is can problems be introduced by not reparsing things, eg if we are editing a .h file, can that affect the symbols of the .c files that include it ... probably possible AFAICT.
Is there some easy way of triggering re-parsing of dependencies when the sidebar is about to swap to a different file? That way real-time update only needs to do the one file being edited, but no artifacts are introduced due to inconsistencies between when tags were parsed.
Cheers Lex
Is the tag parsing even dependency aware? I thought it simply collects tags from all open files (and pre-loaded tag files).
Best regards.
Well its not really dependency aware, in the non-real-time version it does it by reparseing *all* files in the workspace when any one of them is saved, so there can be no inconsistency. It is the fact that its doing all of them on real-time update that is the performance problem, so we want to real-time parse only the file we are editing.
Not being certain what inconsistencies there might be, I'd suggest trying it, only parse the one file real-time and all the others at save time, ie apply Yura's patch (below) and see.
--- a/src/document.c +++ b/src/document.c @@ -2263,7 +2263,7 @@ static gboolean update_tags_from_buffer(GeanyDocument *doc) /* we copy the whole text into memory instead using a direct char pointer from * Scintilla because tm_source_file_buffer_update() does modify the string slightly */ sci_get_text(doc->editor->sci, len, text); - result = tm_source_file_buffer_update(doc->tm_file, (guchar*) text, len, TRUE); + result = tm_source_file_buffer_update(doc->tm_file, (guchar*) text, len, FALSE); g_free(text); #endif return result;
Cheers Lex
Hi,
Le 28/03/2011 05:10, Lex Trotman a écrit :
On 28 March 2011 12:35, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
On 27.03.2011 05:15, Lex Trotman wrote:
The question is can problems be introduced by not reparsing things, eg if we are editing a .h file, can that affect the symbols of the .c files that include it ... probably possible AFAICT.
AFAICT it is possible but unlikely since the only thing that would have this kind of "side effects" is the C/C++ (and probably D) preprocessor (e.g. if a constant changing conditional code changes). Not 100% sure though.
Is there some easy way of triggering re-parsing of dependencies when the sidebar is about to swap to a different file? That way real-time update only needs to do the one file being edited, but no artifacts are introduced due to inconsistencies between when tags were parsed.
I don't know (without further search), but I'm not sure it'd resolve the "issue", since while editing file 1 you wouldn't get the changes from file 2. But again, not sure it's a real issue.
Well its not really dependency aware, in the non-real-time version it does it by reparseing *all* files in the workspace when any one of them is saved, so there can be no inconsistency. It is the fact that its doing all of them on real-time update that is the performance problem, so we want to real-time parse only the file we are editing.
True. Moreover -- as far as I can understand the TagManager code (so, only more or less :D) -- the parent updates will not be done in-memory, so it's definitely a problem we should solve.
Not being certain what inconsistencies there might be, I'd suggest trying it, only parse the one file real-time and all the others at save time, ie apply Yura's patch (below) and see.
Agreed. However the patch would *always* disable updating parent, what we probably don't want (though, not really sure what it'd change). So I have modified it and committed it to SVN (r5642).
Hope this fixes the issue, feedback welcome. And guys, thanks a lot for tracking this down!
Cheers, Colomban
On 29 March 2011 07:37, Colomban Wendling lists.ban@herbesfolles.org wrote:
Hi,
Le 28/03/2011 05:10, Lex Trotman a écrit :
On 28 March 2011 12:35, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
On 27.03.2011 05:15, Lex Trotman wrote:
The question is can problems be introduced by not reparsing things, eg if we are editing a .h file, can that affect the symbols of the .c files that include it ... probably possible AFAICT.
AFAICT it is possible but unlikely since the only thing that would have this kind of "side effects" is the C/C++ (and probably D) preprocessor (e.g. if a constant changing conditional code changes). Not 100% sure though.
Actually the tag manager parses all options since it doesn't know how to evaluate the conditions and then gets confused when something gets defined twice :-)
But on further thought I don't think real-time parsing of only one file makes the problem in any way worse than non-real-time parsing so its ok.
Is there some easy way of triggering re-parsing of dependencies when the sidebar is about to swap to a different file? That way real-time update only needs to do the one file being edited, but no artifacts are introduced due to inconsistencies between when tags were parsed.
I don't know (without further search), but I'm not sure it'd resolve the "issue", since while editing file 1 you wouldn't get the changes from file 2. But again, not sure it's a real issue.
As above I don't think its a problem any more.
Well its not really dependency aware, in the non-real-time version it does it by reparseing *all* files in the workspace when any one of them is saved, so there can be no inconsistency. It is the fact that its doing all of them on real-time update that is the performance problem, so we want to real-time parse only the file we are editing.
True. Moreover -- as far as I can understand the TagManager code (so, only more or less :D) -- the parent updates will not be done in-memory, so it's definitely a problem we should solve.
Probably better to leave it as is rather than potentially use up memory, if its only done at save time.
Not being certain what inconsistencies there might be, I'd suggest trying it, only parse the one file real-time and all the others at save time, ie apply Yura's patch (below) and see.
Agreed. However the patch would *always* disable updating parent, what we probably don't want (though, not really sure what it'd change). So I have modified it and committed it to SVN (r5642).
Ok, oh well, as above, I'm not sure it has any consequences, lets test it and see.
Cheers Lex
Hope this fixes the issue, feedback welcome. And guys, thanks a lot for tracking this down!
Cheers, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, Mar 29, 2011 at 00:04, Lex Trotman elextr@gmail.com wrote:
Agreed. However the patch would *always* disable updating parent, what we probably don't want (though, not really sure what it'd change). So I have modified it and committed it to SVN (r5642).
Ok, oh well, as above, I'm not sure it has any consequences, lets test it and see.
Ah, that is something I can help with!
I'll update to the latest rev first thing tomorrow morning...
-tnx!-
Harold
Le 28/03/2011 22:37, Colomban Wendling a écrit :
[...]
Well its not really dependency aware, in the non-real-time version it does it by reparseing *all* files in the workspace when any one of them is saved, so there can be no inconsistency. It is the fact that its doing all of them on real-time update that is the performance problem, so we want to real-time parse only the file we are editing.
True. Moreover -- as far as I can understand the TagManager code (so, only more or less :D) -- the parent updates will not be done in-memory, so it's definitely a problem we should solve.
This is at least not totally true if I trust strace (no IO during these updates, in facts I had already checked this when I initially wrote the in-memory stuff). At least without geanyprj.
Not being certain what inconsistencies there might be, I'd suggest trying it, only parse the one file real-time and all the others at save time, ie apply Yura's patch (below) and see.
Agreed. However the patch would *always* disable updating parent, what we probably don't want (though, not really sure what it'd change). So I have modified it and committed it to SVN (r5642).
Hope this fixes the issue, feedback welcome. And guys, thanks a lot for tracking this down!
Unfortunately, this change broke calltips (see today's Nick's mail and my answer). I then reverted this, and we have to find a better fix. I'll try to track this further, though I can't promise anything in the next days, nor I know GeanyPRJ, so if anybody beat me in time, it'd be great :D
Regards, Colomban