[Openmcl-devel] Profiling Parenscript compilation

Scott Bell sblist at me.com
Thu Dec 4 16:49:01 PST 2008


Folks,

As a follow-up, I'd like to mention what our bottleneck was. It turned  
out that
we were using some expensive CL-PPCRE scanners to do some basic
dispatching when a simple cons pair would do (although in just a  
slightly
more verbose syntax). It's not entirely clear why this is so different  
in SBCL
vs. CCL, but it's something we plan to investigate.

Pre-optimized parenscript compilation: SBCL 12s, CCL 80s
Post-optimized parenscript compilation: SBCL 0.7s, CCL 0.7s

My first thought is possibly character representation, but I'm not  
that well
acquainted with the joys of Unicode encodings. I will advise further  
once
we get some more information.

Regards,

- Scott


On 4-Dec-08, at 4:56 AM, Hans Hübner wrote:

> Scott,
>
> I committed a fix to the deterministic profiler so that it should now
> work on Darwin, too.  Please give it a try:
>
> (PROF:PROFILE foo) ; profile function foo
> (PROF:PROFILE "FOO") ; profile package "FOO"
>
> (PROF:REPORT) ; write out profiling report
> (PROF:RESET) ; reset profiling
>
> (PROF:UNPROFILE foo) ; unprofile function foo
> (PROF:UNPROFILE-ALL) ; unprofile everything
>
> Note that the profiler must be initialized before any threads are
> started as it uses thread-specific data.  I load it in my
> ccl-init.lisp like so:
>
> (require 'asdf)
> (push (merge-pathnames #P"tools/advice-profiler/"
> (ccl::ccl-directory)) asdf:*central-registry*)
> (asdf:oos 'asdf:load-op :profiler)
>
> Let me know if you have any issues or questions.
>
> -Hans




More information about the Openmcl-devel mailing list