GNOME Bugzilla – Bug 143914
Performance improvement
Last modified: 2005-03-02 16:03:36 UTC
Here is a patch that does five things: - Makes VTE stop outputting spaces. Currently VTE pads each line with spaces. Those spaces propagate all the way through Xft to the X server. - Improves the algorithm to find the next control character in the iso2022 process. The new algorithm stops as soon as it sees a control character, and it does the processing in one pass instead of seven. - Uses a hashtable instead of a tree for the set of ambiguous characters. - Has an additional table of "unambiguous" ranges. - Modifes the input processing to only display after 10 ms, not 2 ms as it does currently. Also use separate coalescing and display timeouts. The result is a good performance improvement. As an example, the benchmark seq -f "testtesttest %g" 100000 takes around 12 seconds with the patch and around 29 without. The numbers varies from run to run though. There is an inherent trade-off between performance and showing what is going on; I think this patch strikes a reasonable balance.
Created attachment 28446 [details] [review] patch
it work :)
+10 Cuts down X and Gnome-terminal traffic a LOT. Very good. Makes gnome-terminal almost bearable to work with.
Has anyone tried this on Solaris? I'm trying on Sol 9 with GNOME 2.6.2, and haven't feeling of better performance :(((
I'm just doing a little cross-referencing work on vte performance bugs since someone posted a patch in 137864 that did part of what Soeren's patch does, and it would have helped to avoid this duplication of work... (In other words, the comments below aren't strictly related to this patch): Note that there are also performance patches in bug 122656 (that appear unrelated to this one), as noted above there's one that was just added to bug 137864 that is a strict subset of Soeren's patch, and comments 29 and 30 of bug 137864 look very interesting (from the maintainer of rxvt-unicode; he compares algorithms and methods used by many different terminal emulation programs and widgets and states his experience).
Soren, please see some comments on this patch near the end of bug 137864.
And can we PUHLEASE get this reviewed and commited if it's good to go?
Notice that in order to compile it with VTE_DEBUG defined this: if (terminal->priv->processing) { shold be: if (vte_terminal_is_processing (terminal)) {
Created attachment 33462 [details] Performance improvements seen with the patch in Solaris
Created attachment 33463 [details] Performance improvements seen with the patch in Linux
I had tried this patch in Solaris and Linux and the performance improvements are very good. Along with this patch, I would suggest one more change: The default vte input buffer size now is 4K. So, changing it to 8K would give some more performance improvements. Actually, in ZVT, input buffer size was already changed from 4K to 8K, to get some performance benifits. We can also follow it. Refer to the above two text file attachments, which measure the performance improvements I got with the patch in Solaris and Linux. (I also mentioned performance improvements after changing 4K buffer size to 8K). Its a too good patch to be missed out. I have seen the patch and most of it makes sense to me. I would like to commit the patch after 10 days, unless someone has concerns.
I think you should post your statment to commit this to desktop-devel mailing list before doing the commit (asuming you have asked the maintainer before and didn't get an answer)
Does anyone know what the status is currently? Is this going to be committed soon?
Duraid: VTE is not maintained. (See http://bugzilla.gnome.org/reports/patch-diligence-report.cgi and note that the one patch that does count as having been reviewed for vte was merely a case where two people submitted the same patch and someone happened to notice and marked them as duplicates)
This patch seems solid and needs to get in, somehow. Elijah, is Arnaud Patard now the VTE maintainer?
I agree, but there's not a whole lot I can do about it; however, maybe I should bug Sven to try to jump in and assist with vte maintainence since he sounded interested. Arnaud Patard wasn't a name I knew anything about so I did some searches in cvs, bugzilla, and through Google. It looks like he might be the maintainer of the Debian package of vte, but that's the only connection I can find.
Please do! (bug Sven) Oops, it does seem he's the Debian vte maintainer - he has included some of the outstanding patches (so I'm happy) but he can't do much else with them (frown)
Be careful with this patch, it seems to cause regression (see bug #163814)
This patch has been used in Fedora Core 3 for a while now with no apparent rush of bugreports. I'm thinking the improvement justifies applying it even if it does cause some problems in other corner cases. Fixing performance for everyone is more important IMO.
Fwiw, I can't reproduce bug 163814; minicom works fine for me. Maybe Mandrake applied some other patch that interferes with this one ...
Hmm, minicom crash is somehow erratic (I can't reproduce it). We are using this patch as well as Benjamin patches from bug #137864.
Used in Fedora too. Commiting.
It looks like the patch was committed, closing. Please re-open if I'm wrong.