Improve performance

[p-e-w]

Final Term's performance is currently very poor due to several issues:

• Lack of settings caching
• Unoptimized rendering pipeline
• ...

Related issues will be linked to this one and closed as duplicates.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[MarkRijckenberg]

Yes, there is an approximately 5 second gap between entering ls -lart in finalterm and getting the output in some cases...

[bl8]

I've noticed that when my finalterm window is just sitting there doing nothing (apart from the cursor blinking), it uses around 10% CPU. Granted, the cursor blinks beautifully, with a nice fade-in and fade-out ;)

I'd suggest that as a first target for performance improvement: use less than 1% CPU when not doing anything.

[p-e-w]

@bl8: Do you have hardware acceleration on your system?

[bl8]

Yes, I'm using the NVidia proprietary driver, version 304.88.
I'm running Ubuntu GNOME 13.04, and using GNOME Shell (which I think doesn't work without hardware acceleration).

[p-e-w]

Partially addressed by 409cc6c.

I measured a rendering speedup factor of 3-10 with this commit depending on the shell program being run.

[p-e-w]

30ad381 brings another substantial speedup.

[p-e-w]

6c29e45 is yet another step towards better performance.

[p-e-w]

And 392e630 is yet another one.

[p-e-w]

The story continues in 90399eb.

[p-e-w]

As for the CPU usage mentioned by @bl8: This appears to be a Clutter/GNOME Shell problem. I see the same behavior on one of my systems and while Final Term does always use 10% CPU there as well, so does gnome-shell (and sometimes xorg as well).

[p-e-w]

Update on CPU usage: It turns out that disabling the cursor animation brings the idle CPU consumption close to zero, with the animation it's around 5-6% on a quadcore.

Who is to blame, then, and how can we fix it? Difficult to say IMO. The fact that the gnome-shell CPU consumption seems to be tied to Final Term's somehow suggests a bug in the rendering stack rather than FT.

[p-e-w]

Another piece in the CPU usage puzzle: Every animation cycle apparently forces a complete repaint of line_container, which is where the CPU usage actually occurs.

[p-e-w]

See https://mail.gnome.org/archives/commits-list/2009-October/msg00814.html for a Clutter application that seems to have had a similar problem.

Their solution: Disable the animation. This is a massive problem with Clutter if disabling the animation is indeed the only way to lower CPU usage.

[p-e-w]

Another huge performance improvement comes with bc408a9, which at last brings constant-time adding of LineViews.

Final Term's performance (i.e. speed) is now roughly 8 times slower than GNOME Terminal's, which I find sufficient for an initial release. The only issue left in this bug is the absurdly high CPU consumption.

[x2q]

+1

ps axu takes ~60 secs and consumes only a single cpu core

[p-e-w]

@x2q: Are you using the latest master (note that the PPA is currently not building, and thus outdated)? Because on all my machines, ps axu now takes less than a single second.

[schlingel]

+1

When running repeatedly ant tasks (timespan is about 4h) the terminal gets so slow that I have to restart it. After that it works again, for about 4h.

[arkocal]

Autocomplete gets unacceptably slow after many commands are given, especially when typing frequent phrases like sudo foo. It also blocks rendering.

[p-e-w]

@arkocal: Yes, I noticed that, though only after I upgraded to GNOME Shell 3.10 earlier this year. Should be possible to make it a lot faster given that all autocomplete data is in memory (maybe by limiting the number of results).