[fomus-devel] v0.2.12

[David Psenicka]

>From what I can tell, openmcl was spending a lot of time instantiating
some of the classes I had defined (although according to 
http://www.cliki.net/Performance%20Benchmarks2  openmcl should be pretty
fast at this).  so I'd have to do more profiling to be sure that that's
what it really was--all of my profiling tests kept pointing to the
make-instance functions in splitrules.lisp (which generates rules for
splitting measures, etc.)--the real problem was in another part of the
program anyways (the quantizing search engine) which generated much more
of these rules than were necessary, so I fixed this which seemed to fix
the problem.  (it was a pretty dumb error, but it makes the difference
between having to instantiate tens-of-thousands of CLOS classes and
generating only a few hundred)

I'd like to know how it runs w/ your input--I'd wait until I'm done
retesting this in all the different lisps/platforms though (in a day or
two), there are a few issues in the module loading/compiling that I have
to make sure are fixed...  :)  (or you can tell fomus to skip the
modules part when it loads by adding a FOMUS-NOAUTOREG to *features* &
recompiling)


Rick Taube wrote:
> id be interested in knowing what the issues were that resulted in the
> slowdown in openmcl. when i was notating my last piece i heard the
> disk chatter quite a bit, i thought perhaps it was something with vmem
> but apparently not...
> ill have to try the new version with some input that took several
> minutes -- i dont knwo if quantizing was on or not (i used the
> defaults) but i was specfiying time values as rationals.
>