[Openmcl-devel] Profiling Parenscript compilation

[Gary Byers]

I think that there are some parameters in CL-PPCRE that control:

- whether or not to create some tables (vectors) that can speed up
matching of literal prefixes and suffixes, and this parameter defaults
to T.

- how large to make those vectors; the default is CHAR-CODE-LIMIT,
which is #x110000 in CCL and many other lisps.

I think that we've seen cases (maybe involving precompiled regular
expressions) where memory fills up with lots of very large, mostly
empty vectors; in the case where this was happening, the tables didn't
seem to speed things up, and their memory cost was pretty severe.  I
don't know if that's related to the speed issue, but if these tables
were being allocated and initialized at runtime - over and over again
- it's not hard to imagine that you'd be spending more time doing
that than doing something more useful.  (If you were allocating
and initializing 128-entry or 256-entry tables, that might still
be worthwhile in some cases; #x110000-entry tables ... not so much.)



On Thu, 4 Dec 2008, Scott Bell wrote:

> 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
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>