[gsharp-devel] redraw buglets

[Robert Strandh]

Christophe Rhodes writes:
 > 
 > Still really bignum-gcd dominated, I'm afraid.  Your hypothesis about
 > McCLIM coordinates is certainly possible...

I took a better look at this, and found that it is not at all the
Gsharp measure computation that takes time.  In fact, for C-f and C-b,
it is not even invoked, and even when it is, it is very fast.  So that
is good news.

The time spent in drawing routines.  Looking at the low-level CLIM
code, a lot of time is, as you pointed out, spent in
map-over-output-records-containing-position.  In fact, on my machine,
doing C-f 50 times, gives almost 10 seconds in this function, for a
total of 3000 calls or so.  

Tim will correct me if I am wrong, but I suspect this is because
compound output records are only sequential at the moment.  The Gsharp
score pane should have a smarter organization of output records that
takes into account the layout of printed music on a page. 

In other words, it may not be worth more time (as far as Gsharp is
concerned) optimizing GCD, even though that is a good thing in
general, since the solution is to do something smarter in the score
pane. 

It seems more and more plausible to me that getting the score pane
right is high priority: it is needed to get better performance, it is
crucial in terms of modularity, and it is needed by others (the
OpenMusic project at IRCAM). 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------