Dear mcclim-devel,
It looks like find-keystroke-item is doing a lot of work (linear search through the keystrokes) every time there's a key event. I know this is the lispy way to do things, and clim wants to be flexible enough to provide other tests besides event-matches-gesture-name-p, but this seems like an awful lot of work for every key stroke. Am I missing something here?
BTW, I bring this up to try to address the generally poor response I get typing in climacs with the beagle back end.
Thanks,
Cyrus
Cyrus Harmon writes:
Dear mcclim-devel,
It looks like find-keystroke-item is doing a lot of work (linear search through the keystrokes) every time there's a key event. I know this is the lispy way to do things, and clim wants to be flexible enough to provide other tests besides event-matches-gesture-name-p, but this seems like an awful lot of work for every key stroke. Am I missing something here?
BTW, I bring this up to try to address the generally poor response I get typing in climacs with the beagle back end.
I seriously doubt that find-keystroke-item is the source of your problem. While you are right, that it is doing a sequential search, it does so at interaction speed which is thousands of times slower.
Have you profiled it to be sure that this is really the source of the poor response?
Ok, here's where I admit to not really knowing how to use a profiler for lisp code :-). But, keystroke processing seems like a pretty fundamental part of what an editor needs to do.
70 wpm ~= 400 char/min = 6 char/sec. We're looking at ~100 things on the list per char, so we're doing roughly 1000 comparisons per second. Not good.
Admittedly, (time ...) doesn't show that this isn't a bottleneck, but something somewhere between pressing the keystrokes and displaying the corresponding characters is slow. Plus, we're apparently (with openmcl at least) 500 bytes or so per trip through here. If I type 1000 characters, I've just consed up 500kb of stuff I need to GC? I guess memory allocation is fast, and the GC quick too, but it seems like we could be doing a hash lookup here and not consing.
If you've got better places for me to look for the bottlenecks between typing and display, let me know.
Thanks,
Cyrus
On Jan 26, 2005, at 8:52 PM, Robert Strandh wrote:
I seriously doubt that find-keystroke-item is the source of your problem. While you are right, that it is doing a sequential search, it does so at interaction speed which is thousands of times slower.
Have you profiled it to be sure that this is really the source of the poor response?
Cyrus Harmon ch-mcclim@bobobeach.com writes:
Ok, here's where I admit to not really knowing how to use a profiler for lisp code :-).
I don't know what facilities OpenMCL provides for profiling. However, other implementations provide multiple methods for finding out where time is spent; even if you're not using those implementations for development, you can use them to get an idea where the bottleneck is.
But, keystroke processing seems like a pretty fundamental part of what an editor needs to do.
Don't judge by what seems to be obvious. Really. You will be wrong.
70 wpm ~= 400 char/min = 6 char/sec. We're looking at ~100 things on the list per char, so we're doing roughly 1000 comparisons per second. Not good.
* (defvar *magic* (cons nil nil)) * (time (let ((x (cons nil nil))) (dotimes (i 1000000) (eql x *magic*))))
Evaluation took: 0.167 seconds of real time 0.166975 seconds of user run time
so 1000 comparisons will take about 0.0002 seconds. That leaves 0.9998 seconds for other processing. I'm pretty sure that 1000 comparisons is truly insignificant, but on the other hand I haven't measured your setup, only mine.
If you've got better places for me to look for the bottlenecks between typing and display, let me know.
Use a profiler. Really. Don't guess.
Cheers,
Christophe
Cyrus,
I might suggest using a program called valgrind. You can run other programs under it and it will give you useful profile information.
Tim Daly
-
Christophe Rhodes -
Cyrus Harmon -
Robert Strandh -
root