RegExp performance

Lars Hansen lhansen at adobe.com
Tue Jun 24 07:50:05 PDT 2008


It would be interesting to know why that allocation is going on.  RE
execution should need to allocate for suspended decision points and for
capture arrays, but I would have hoped the engine had optimized those
significantly to avoid hitting the allocator all the time.  What do the
test cases look like, and why do they tickle such an allocation volume?

--lars

> -----Original Message-----
> From: tamarin-devel-bounces at mozilla.org [mailto:tamarin-devel-
> bounces at mozilla.org] On Behalf Of Michael Daumling
> Sent: 24. juni 2008 16:43
> To: tamarin-devel at mozilla.org
> Subject: RegExp performance
> 
> Hi all,
> 
> I have used GlowCode (yet another profiling tool that you can test for
> 21 days) to examine RegExp performance in TT.
> 
> The big surprise was that _pcre_exec does a *lot* of mallocs and free
> (plus a ton of setjmp/longjmp). The difference between TC and TT is
> that
> TC has a global override of operators new and delete (in AvmShell.cpp)
> that uses FixedMalloc::Alloc/Free, and TT uses malloc and free via the
> default global new and delete operators.
> 
> Switching the pcre allocators (in pcre_globals.cpp amd
RegExpClass.cpp)
> to using FixedMalloc showed a very nice improvement, but only in
> GlowCode. In the real world, the ecma3/Unicode tests were slower!
> 
> I am out of knowledge here. Is it possible that
FixedMalloc::Alloc/Free
> is slower in TT than in TC? Should I have tried a different (fast)
> replacement for malloc/free? Was the usage of malloc/free intentional
> at
> all?
> 
> BTW: String handling (UTF-8 conversion etc) is negligible in that
> context. The big hog is malloc/free from within _pcre_exec (about 60%
> of
> total time).
> 
> Michael
> 
> _______________________________________________
> Tamarin-devel mailing list
> Tamarin-devel at mozilla.org
> https://mail.mozilla.org/listinfo/tamarin-devel


More information about the Tamarin-devel mailing list