After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 730732 - printing img.sh's output in large terminal is very slow
printing img.sh's output in large terminal is very slow
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.37.x
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-05-25 20:17 UTC by Egmont Koblinger
Modified: 2014-05-26 11:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Tadaaaa! (800 bytes, patch)
2014-05-25 22:07 UTC, Egmont Koblinger
none Details | Review
Fix v2 (bit of cleanup) (1.38 KB, patch)
2014-05-26 11:12 UTC, Egmont Koblinger
committed Details | Review

Description Egmont Koblinger 2014-05-25 20:17:41 UTC
Large terminal (small font size, maximized window)
perf/img.sh [some_picture] > x
cat x  # multiple times if necessary

This is extemely slow.

As long as no scrolling is required, it is reasonably fast. It gets slow when the terminal starts scrolling.

Notice that while cat'ing the file and scrolling, it is still sometimes quite fast, but sometimes gets painfully slow, basically you can see the lines getting printed one by one. 

There's a huge variance in the time required. In a freshly started vte of 272x70 size, no other apps using CPU, cating the file from bug 730599 10 times can easily take anywhere between 7 and 16 seconds on my system.

[Note: img.sh itself is slow, this is irrelevant here. That's why its output is first redirected to a file.]
Comment 1 Egmont Koblinger 2014-05-25 20:23:16 UTC
Increasing VTE_*_TIMEOUT values 10-fold makes the aforementioned time drop to consistently around 4 seconds.

My guess is that updating the display takes so much time that by the time it completes the timeout has elapsed again, kicking in another update. So basically vte spends most of its time updating the display, hardly processing any input in between.

I think the timer should pause for the duration of updating. E.g. the next timer should not fire N ms after the previous one has fired, but N ms after the previous update has finished.

(Just a wild idea so far, I haven't studied the code yet.)
Comment 2 Egmont Koblinger 2014-05-25 22:07:54 UTC
Created attachment 277162 [details] [review]
Tadaaaa!

My guess was right. With this patch, the given command completes in 2s.
Comment 3 Egmont Koblinger 2014-05-25 23:22:47 UTC
I should further clean up the patch.

The newly added lines should be merged with the previous branch.

We now have two methods: update_timeout() and update_repeat_timeout() copy-pasting tons of code, with differences (e.g. redraw vs. again) that are hard to verify that are logically the same.

I guess we can safely live with just update_timeout(), which may install a new timeout to itself...
Comment 4 Egmont Koblinger 2014-05-26 11:12:41 UTC
Created attachment 277194 [details] [review]
Fix v2 (bit of cleanup)

Just a little cleanup.

[There are actually 3 very similar methods: process_timeout(), update_timeout() and update_repeat_timeout().  I'm not brave enough to merge them, there a few minor differences that I'd need to fully understand.  I'm not planning to work on this.]
Comment 5 Egmont Koblinger 2014-05-26 11:22:16 UTC
Comment on attachment 277194 [details] [review]
Fix v2 (bit of cleanup)

Committed as b8db6a2.