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.