[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