Skip Menu |

This queue is for tickets about the Tangram CPAN distribution.

Report information
The Basics
Id: 27341
Status: stalled
Priority: 0/
Queue: Tangram

People
Owner: SAMV [...] cpan.org
Requestors: nomad [...] null.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: TRACE performance issue related to regular expression
Date: Wed, 30 May 2007 14:09:49 +0200 (CEST)
To: bug-Tangram [...] rt.cpan.org
From: Mark Lawrence <nomad [...] null.net>
Hi, Occasionally (took me ages to track down) I've had a huge slowdown (of the order of half a second) with certain queries when TANGRAM::TRACE and TANGRAM::DEBUG_LEVEL were set. I narrowed it down to the debugging statement at Tangram/Relational/PolySelectTemplate.pm:253 The attached program duplicates that statement with the input being generated by my program to get the execution times. When I run it on my Fujitsu Lifebook S2110 (about 1 year old) I get the following timings: 0.0017859935760498 0.545166015625 <========== WT? 0.000358104705810547 0.00082087516784668 0.00049901008605957 0.000385046005249023 I'm guess that this is actually some issue with the Perl regular expression engine, not Tangram. However if there are any RE gurus who know what's going on, and more importantly how to rewrite this expression to stop this from happening I'd appreciate it. Have to comment out that expression for now... (or have no debugging). The query that generates this input looks like this: my $rem = $self->{storage}->remote('Node'); my $remt = $self->{storage}->remote('NodeT'); my $filter = ( (($rem->{parent} == $self->{root}) | ($rem->{path} == '/')) & ($rem->{menuitem} > 0) & ($rem->{published} > 0) & (($remt->{transof} == $rem->{id}) & (($rem->{visnotrans} > 0) | ($remt->{lang} eq $self->{lang}))) ); my @children = $self->{storage}->select($rem, filter => $filter, distinct => 1, ); Cheers, Mark. -- Mark Lawrence

Message body is not shown because sender requested not to inline it.

From: SAMV [...] cpan.org
On Wed May 30 08:13:37 2007, nomad@null.net wrote: Show quoted text
> Hi, > > Occasionally (took me ages to track down) I've had a huge slowdown (of > the > order of half a second) with certain queries when TANGRAM::TRACE and > TANGRAM::DEBUG_LEVEL were set. > > I narrowed it down to the debugging statement at > > Tangram/Relational/PolySelectTemplate.pm:253 > > The attached program duplicates that statement with the input being > generated by my program to get the execution times. When I run it on > my > Fujitsu Lifebook S2110 (about 1 year old) I get the following timings: > > 0.0017859935760498 > 0.545166015625 <========== WT? > 0.000358104705810547 > 0.00082087516784668 > 0.00049901008605957 > 0.000385046005249023 > > I'm guess that this is actually some issue with the Perl regular > expression engine, not Tangram. However if there are any RE gurus who > know > what's going on, and more importantly how to rewrite this expression > to > stop this from happening I'd appreciate it. Have to comment out that > expression for now... (or have no debugging). > > The query that generates this input looks like this: > > my $rem = $self->{storage}->remote('Node'); > my $remt = $self->{storage}->remote('NodeT'); > my $filter = ( > (($rem->{parent} == $self->{root}) | ($rem->{path} == '/')) > & ($rem->{menuitem} > 0) > & ($rem->{published} > 0) > & (($remt->{transof} == $rem->{id}) & > (($rem->{visnotrans} > 0) | ($remt->{lang} eq $self-
> >{lang})))
> ); > my @children = $self->{storage}->select($rem, > filter => $filter, > distinct => 1, > ); > > Cheers, > Mark.
Yep. It's clearly a bit too clever for its own good isn't it! the non-backtracking assertion (see L<perlre/(?>pattern)>) is the way to avoid the O(N³²) or whatever it is performance that you're seeing. Those need to be peppered in at suitable places. My long term plan for this was to use SQL::Builder and avoid having to reverse engineer the structure from the SQL text - as the comments in the code notes, it's a dirty hack. Working on setting up a git.or.cz clone on utsl so you can push your patches there :-). Got your other one, which looks good. Sam.