[gsharp-devel] redraw buglets

[Robert Strandh]

Christophe Rhodes writes:
 > Christophe Rhodes <csr21 at cam.ac.uk> writes:
 > 
 > > Can you give me instructions on what you're doing to trigger the
 > > redraw?  Alternatively, you may wish to try this running under the
 > > statistical profiler provided by sbcl -- loaded with (require
 > > :sb-sprof).
 > 
 > I've played around with this idea a little, and have some slightly
 > surprising results.  Apparently, at least for sbcl, the bottleneck is
 > bignum gcd.  The top 20 functions (statistically sampled by loading
 > rapsoden-sjunger.gsh into gsharp and then leaning on C-f) are
 > 
 >    1    231   6.2    231   6.2 SB-BIGNUM:BIGNUM-GCD
 >    2    177   4.8    408  11.0 "&MORE processing"
 >    3    164   4.4    572  15.5 SB-BIGNUM::MAKE-GCD-BIGNUM-ODD
 >    4    140   3.8    712  19.3 "#'(LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. ...) (DECLARE #) ...)"
 >    5    129   3.5    841  22.8 SB-BIGNUM::SUBTRACT-BIGNUM-BUFFERS
 >    6    116   3.1    957  25.9 "#'(SB-KERNEL:INSTANCE-LAMBDA (SB-PCL::.ARG0.) (LET NIL # ...))"
 >    7    116   3.1   1073  29.0 SB-KERNEL:TWO-ARG-+
 >    8     99   2.7   1172  31.7 SB-BIGNUM::BIGNUM-BUFFER-ASHIFT-RIGHT
 >    9     91   2.5   1263  34.2 ASH
 >   10     83   2.2   1346  36.4 "#'(SB-KERNEL:INSTANCE-LAMBDA (SB-PCL::.ARG0. SB-PCL::.ARG1.) (LET NIL # ...))"
 >   11     80   2.2   1426  38.6 SB-BIGNUM::BIGNUM-GCD-ORDER-AND-SUBTRACT
 >   12     77   2.1   1503  40.7 SB-KERNEL:CLASSOID-TYPEP
 >   13     77   2.1   1580  42.7 SB-KERNEL::%%TYPEP
 >   14     63   1.7   1643  44.5 SB-VM::GENERIC-+
 >   15     56   1.5   1699  46.0 SB-BIGNUM::BIGNUM-TRUNCATE-SINGLE-DIGIT
 >   16     54   1.5   1753  47.4 SB-KERNEL::INTEGER-/-INTEGER
 >   17     53   1.4   1806  48.9 SB-BIGNUM::%NORMALIZE-BIGNUM-BUFFER
 >   18     53   1.4   1859  50.3 "hairy arg processor for top level local call SB!BIGNUM::BIGNUM-ASHIFT-LEFT-UNALIGNED"
 >   19     52   1.4   1911  51.7 GETHASH
 >   20     51   1.4   1962  53.1 TRUNCATE
 > 
 > Unfortunately, this isn't yielding information about why it's spending
 > so much time in GCD, though my suspicion would land on integer or
 > ratio division.

I suspect you are right.  I use fractions alot, and the GCD would be
called not only for division, but also for additions, multiplications,
etc. 

 > [ No, I don't know what "&MORE processing" is doing quite so high: it
 >   seems to be connected to certain methods, particuarly
 >   MAP-OVER-OUTPUT-RECORDS-CONTAINING-POSITION ]

I am willing to believe that.  

-- 
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.
---------------------------------------------------------------------