Ticket #11 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

Performance: typing is perceptibly slow.

Reported by: fperez Assigned to: tzanko
Priority: normal Milestone:
Component: nbshell Version:
Severity: normal Keywords:
Cc:

Description

[I've moved here an entry from the Todo as its own ticket so we can track it better]

Performance worries me: there is a perceptible typing lag at each character. I don't know if this is a problem inherent in the WX widget being used, and not something we can fix. But if there are optimizations possible that can make the interactive typing as fluid as in a terminal, it would be great.

TZANKO: My machine is Athlon XP 1.4Ghz, 256 MB RAM, using the wxWidgets-GTK2 with using libgtk 2.6.9 and I don't have any performance issues. If your machine is faster than the problem is somewhere else.

fperez: I'm on a slower box (1.13 GHz laptop with 512 MB RAM), and the lag is really perceptible. For example, it's noticeably slower than typing in this edit box (Firefox), which is also a GTK text widget. I wonder if WX is doing just too much on every keystroke. For reference, if I type here (Firefox edit box) I can't feel any lag between characters, and the CPU load hovers around 15-20%. In contrast, nbshell pegs at 99% CPU load while I'm typing, and the characters can't quite keep up with my typing.

This may be hard to debug, but I want to keep track of the problem because eventually it will have to get fixed.

Change History

09/10/05 01:21:50 changed by fperez

I've made some progress on this one.

In PythonPlugin.py, uncomment line 368. You'll see that this gets printed on every keystroke. If you stick something that causes an exception in there you can see how deep the stack is there.

This means that we're doing a LOT of work on every keystroke just to determine the prompt length. Since the length of the prompt can be determined at new cell startup (it only depends on the template and number), this number should be statically cached for each cell.

Then, this routine GetPrompt? should only get called when a new prompt actually has to be rendered (such as for making '...' markers whenever a line is added).

Fixing this will probably help, though there may be other areas with similar problems. I'm sure we can improve the interactive response quite a bit with some tuning.

09/13/05 12:16:07 changed by tzanko

  • status changed from new to assigned.

I made the optimizations, now the prompt length is determined when the whole block is updated. I cannot tell the difference on my computer, though. Does this fix the problem?

09/17/05 16:03:32 changed by tzanko

  • status changed from assigned to closed.
  • resolution set to fixed.