GNOME Bugzilla – Bug 722065
make vte faster
Last modified: 2021-06-10 14:47:29 UTC
So with either the straight revert of the commit identified in bug 721944, or the Real Fix™ patch from there, I only get a 4x speedup back (from ~50s to ~12s) on vte-0-36. Also, on a more involved testcase (img.sh animated.gif > test; time cat test) the revert is 3x faster than the Real Fix™. Since 0.28.2 was about the same speed with revert/real-fix as vte-0-36, I bisected between 49a0cdf and 0.28.2, with revert or real-fix applied, towards the lowest time, recording perf for all tested comits along the bisect. From that record I then picked the next regression window to bisect, and proceeded the same, etc. This was possible since it turned out that instead of a creeping slowing, perf was stable, and commits introducing perf regression were clearly identifiable. Someone could also bisect 0.28 to 0-36, to see if there were also perf regression that have just been masked by unrelated perf improvements. 49a0cdf: revert 5.3s , real-fix 5.3s 04f263a: revert 5.4s , real-fix 5.3s 5dd988d: revert 5.35s, real-fix 5.35s 2905d91: revert 5.30s, real-fix 5.3s 37472ef: revert 5.30s, real-fix 5.25s 8894e57: revert 5.85s, real-fix 5.85s (crashes on repeating 'cat test') https://git.gnome.org/browse/vte/commit/?h=vte-0-36&id=8894e5764a8e27e87be8a965851113bb02052e7a is the first bad commit commit 8894e5764a8e27e87be8a965851113bb02052e7a Author: Behdad Esfahbod <behdad@gnome.org> Date: Sat Nov 29 06:00:17 2008 +0000 Bug 514632 – Problem with cursor in emacs in gnome-terminal 2008-11-29 Behdad Esfahbod <behdad@gnome.org> Bug 514632 – Problem with cursor in emacs in gnome-terminal * src/vte-private.h: * src/vte.c (_vte_terminal_cleanup_tab_fragments_at_cursor), (_vte_terminal_insert_char): * src/vteseq.c (vte_sequence_handler_ch), (vte_sequence_handler_cm), (vte_sequence_handler_le), (vte_sequence_handler_cursor_character_absolute): Break "smart tabs" into multiple empty cells when cursor moves into them or inserting character there. svn path=/trunk/; revision=2222 8894e57: revert 5.85s, real-fix 5.85s (crashes on repeating 'cat test') c1acc92: revert 5.9s , real-fix 5.9s (crashes on repeating 'cat test') a00ed36: revert 5.9s , real-fix 5.9s (crashes on repeating 'cat test') 4a60f3e: revert 5.7s , real-fix 5.7s (crashes on repeating 'cat test') 4afa82b: revert 5.7s , real-fix 5.7s (crashes on repeating 'cat test') [seems perf improved here, someone should bisect to make sure there's no worsening perf hidden] 58bc3a9: revert 5.3s , real-fix 5.3s 3eaca3e: revert 5.2s , real-fix 5.2s 83018a7: revert 5.3s , real-fix 5.25s c34204b: revert 5.2s , real-fix 5.2s 68ac36d: revert 5.2s , real-fix 5.15s b2280c0: revert 5.2s , real-fix 5.2s ba1f44d: revert 5.6s , real-fix 5.4s https://git.gnome.org/browse/vte/commit/?h=vte-0-36&id=ba1f44d6119cc39602d8a660f4e5a9f56a6f19da is the first bad commit commit ba1f44d6119cc39602d8a660f4e5a9f56a6f19da Author: Behdad Esfahbod <behdad@behdad.org> Date: Thu Aug 20 23:03:50 2009 -0400 Specialize VteRing to know about VteRowData ba1f44d: revert 5.6s , real-fix 5.4s 7a2a78d: revert 5.5s , real-fix 5.45s bf5977d: revert 5.5s , real-fix 5.3s 4e533b1: revert 5.95s, real-fix 6.2s https://git.gnome.org/browse/vte/commit/?h=vte-0-36&id=4e533b106a1c39b8565a9891fba83e384cc40669 is the first bad commit commit 4e533b106a1c39b8565a9891fba83e384cc40669 Author: Behdad Esfahbod <behdad@behdad.org> Date: Fri Aug 21 12:17:38 2009 -0400 Revert 80dc9064 Removing the optimization, so I can clean up the ring API and redesign the implementation. Sorry Chris! 4e533b1: revert 5.95s, real-fix 6.2s 031a653: revert 6.0s , real-fix 6.0s 4e20a3b: revert 5.95s, real-fix 5.95s 4407376: revert 6.75s, real-fix 6.7s https://git.gnome.org/browse/vte/commit/?h=vte-0-36&id=440737678453a83e812ee60545369ec0e54a4759 is the first bad commit commit 440737678453a83e812ee60545369ec0e54a4759 Author: Behdad Esfahbod <behdad@behdad.org> Date: Fri Aug 21 21:01:17 2009 -0400 Move _vte_new_row_data() business into the ring 4407376: revert 6.75s, real-fix 6.7s 9a3de3c: rever 6.6s , real-fix 6.6s 689990d: revert 6.5s , real-fix 6.5s 674f91f: revert 8.6s https://git.gnome.org/browse/vte/commit/?h=vte-0-36&id=674f91ff949f532b7037c9aba658ad5ea3330a91 is the first bad commit commit 674f91ff949f532b7037c9aba658ad5ea3330a91 Author: Behdad Esfahbod <behdad@behdad.org> Date: Tue Aug 25 18:11:05 2009 -0400 Remove G_DISABLE_ASSERT 674f91f: revert 8.6s edea8ad: revert 8.5s , real-fix 8.5s 4319059: rever 8.5s , real-fix 8.5s (crash on exit: vtepangocairo.c:188:unistr_info_finish: code should not be reached) 8ad1d69: revert 8.5s , real-fix 8.4s dd06b76: revert 8.5s ea6488d: revert 8.8s a74e9fb: revert 8.9s dd06b76: revert 8.9s 717f5bc: revert 8.5s [commit 684e66aeb8597e9f54fda6361ef9e337fdb44eda is the one which improves perf here] 684e66a: revert 7.5s 41f2912: revert 7.5s , real-fix 7.5s 8cb3e37: revert 7.6s f73e04e: revert 7.7s 96793d9: revert 7.7s https://git.gnome.org/browse/vte/commit/?h=vte-0-36&id=6cf23eeb0237858b7b769074ed9c5bb564c3d is the first bad commit commit 71a6cf23eeb0237858b7b769074ed9c5bb564c3d Author: Behdad Esfahbod <behdad@behdad.org> Date: Thu Aug 27 17:07:53 2009 -0400 [ring] Fix brokenness with macro implementation 71a6cf2: revert 8.1s cbb3071: revert 8.1s 00566ad: revert 8.1s , real-fix 8.0s 9f486df: revert 8.1s [commit fb9a0d3727c12c0dd5de384335050bb416d33815 is the one which improves perf here] fb9a0d3: revert 7.8s https://git.gnome.org/browse/vte/commit/?h=vte-0-36&id=064822346af55ce36e0a7e82b38bf235e9fb394f is the first bad commit commit 064822346af55ce36e0a7e82b38bf235e9fb394f Author: Behdad Esfahbod <behdad@behdad.org> Date: Sat Sep 5 00:06:38 2009 -0400 [ring] Remove GArray for rowcell allocation A very dumb allocator right now. To be optimized. [ChPe: likely fixed already] 0648223: revert 10.8s 2ce6acc: revert 10.9s c6b2621: revert 11.0s 2ce6acc: revert 11.0s 7b7bea5: revert 7.3s 475606d: revert 7.1s 1cd88dc: revert 6.6s 3300760: revert 6.7s 7d4895e: revert 6.8s d77e97e: revert 6.7s 17840c4: revert 6.7s fc9a6da: revert 7.0s https://git.gnome. https://git.gnome.org/browse/vte/commit/?h=vte-0-36&id=fc9a6daf6394642e17e8aa76cbe661f0f08e8a68 is the first bad commit commit fc9a6daf6394642e17e8aa76cbe661f0f08e8a68 Author: Behdad Esfahbod <behdad@behdad.org> Date: Wed Sep 9 21:26:46 2009 -0400 [ring] Separate VteRowData and VteCompactRowData fc9a6da: revert 7.0s cea0b21: revert 7.1s 9ad227f: revert 7.1s a63c3d6: revert 6.9s https://git.gnome.org/browse/vte/commit/?h=vte-0-36&id=a88338e07429a5ce1fc4cb081448333c699f7f23 is the first bad commit commit a88338e07429a5ce1fc4cb081448333c699f7f23 Author: Behdad Esfahbod <behdad@behdad.org> Date: Sat Sep 12 19:40:02 2009 -0400 [ring] Port to VteStream Not optimized, simple file-based non-compact storage a88338e: revert 28.8s 2eefab8: revert 29.0s ea7ee1b: revert 29.2s 39b7a1f: revert 12.8s 7561724: revert 12.7s b1379dc: revert 12.6s 122d638: revert 12.6s ae08c6d: revert 12.6s 4423625: revert 12.8s 2a325bd: revert 12.7s 63ba68f: revert 13.2s ab66ce5: revert 12.7s 3a37564: revert 13.1s 0.28.2 : revert 13.0s, real-fix 11.8s
Can you test with newest tree that uses stdio for scrollback? What's the bottomline? Do we know what's being really bad right now?
Using my 'find / > test; time cat test' testcase, current vte-0-36 is at 11.7s, while 0.28 (with the 1-line patch from bug 721944) is at 11.8s (see comment 0 last line). So they're about equal. Looking at a sysprof profile, for that testcase, almost 90% of time is spent in vte_terminal_process_incoming(), of which almost half is going to _vte_terminal_insert_char(), and 12% each to _vte_terminal_handle_sequence() and _vte_iso20200_process, then 8% for _vte_matcher_match(), 2.5% to _vte_terminal_emit_pending_signals(). For a escape sequence heavy input (like img.sh animated.gif > test; time cat test) the perceived perf is worse, but curiously process_incoming only takes 20% of which emit_pending_signals is now half ... weird.
Actually turns out I bisected using -O2 while my vte-0-36 was using -O0 -fno-inline. Using -O2 on 0-36 resulted in the testcase being reduced to 8.3s, so vte-0-36 is a bit faster than 0.28.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2050.