At 11:16 AM 01/27/02 +0800, Stas Bekman wrote: >Hmm, you were trying this on uloaded machine, right? If you have many >parallel searches and other tasks running this can be much much slower, no?
I didn't see much difference on apache.org: [EMAIL PROTECTED]:/home/stas/apache.org/modperl-docs >time find src -name '*.pod' | xargs fgrep '$|' src/docs/1.0/faqs/cgi_to_mod_perl.pod: local $| = 1; src/docs/1.0/guide/control.pod: ($name) = $0 =~ m|([^/]+)$|; src/docs/1.0/guide/debug.pod: $| = 1; src/docs/1.0/guide/debug.pod: $|=1; src/docs/1.0/guide/debug.pod:I<http://localhost/perl/debug/perl_trace.pl>, we have used C<$|=1;> src/docs/1.0/guide/debug.pod: $|=1; src/docs/1.0/guide/debug.pod:that I've made STDOUT unbuffered with C<$|=1;> so I will immediately src/docs/1.0/guide/performance.pod: local $| = 1; src/docs/1.0/guide/performance.pod: local $| = 1; src/docs/1.0/guide/performance.pod:The localized setting of C<$|=1> unbuffers the STDERR stream, so we src/docs/1.0/guide/performance.pod: local $| = 1; src/docs/1.0/guide/performance.pod:=head2 Using $|=1 Under mod_perl and Better print() Techniques. src/docs/1.0/guide/performance.pod:As you know, C<local $|=1;> disables the buffering of the currently src/docs/1.0/guide/performance.pod:performance degradation with C<$|=1>. It also uses too many src/docs/1.0/guide/performance.pod:Now let's go back to the C<$|=1> topic. I still disable buffering, src/docs/1.0/guide/perl.pod:Special Perl variables like C<$|> (buffering), C<$^T> (script's start src/docs/1.0/guide/porting.pod: local $| = 1; src/docs/1.0/guide/scenario.pod: BEGIN{ $|=1 } src/docs/1.0/guide/scenario.pod: $|=1; src/docs/1.0/guide/scenario.pod:You must disable buffering. C<$|=1;> does the job. If you do not src/docs/2.0/devel/debug_c/debug_c.pod: BEGIN { $| = 1; print "1..1\n"; } src/docs/2.0/devel/testing/testing.pod: $response_test =~ s|t/[^/]+/Test([^/]+)/(.*).pm$|t/\L$1\E/$2.t|; src/docs/2.0/devel/testing/testing.pod: $response_test =~ s|.*/([^/]+)/(.*).pm$|/$1::$2|; real 0m0.048s user 0m0.015s sys 0m0.036s But Maybe I'm not using time correctly. Let's see... [EMAIL PROTECTED]:/home/stas/apache.org/modperl-docs >time find src -name '*.pod' | xargs fgrep '$|' | sleep 5 real 0m5.009s user 0m0.033s sys 0m0.012s Looks like it's counting total time. >Also remember that user doesn't care about CPU clocks, but elapsed >wallclock. That's "real" time above. Again, how many searches a second are you expecting? We aren't running google loads here. ;) >Also which OS/distro are you running this at? That's on my P550 Linux with an old Kernel. daedalus is always faster than my machine -- even when it's load average is high. Dual 850s and fast SCSI (and BSD's I/O) seems to do the trick. >0.120u 0.170s 0:00.31 93.5% 0+0k 0+0io 18193pf+0w > >as you can see it's much slower. >> Could we feed the pod source into Parse::RecDescent and get it to tokenize >> perl code? That would be more fun. > >I guess so, but from what I know, Parse::RecDescent is not good for >real-time processing because it's very slow. Rememember that it stores >the parsed tree using Perl datastructures, which is very ineffective. I >don't know if it was rewritten to use C datastructures since last year. My idea was not for parsing while searching, rather parsing while indexing. The parsing of a tiny query wouldn't take long. But I was also kind of joking, but it would be interesting, too. I'm not sure what to parse into. Should $x++ get parsed into "$x", "$x++", or "$x and ++"? Do a normal indexed search for most, but offer an option to search for perl code and then use fgrep. -- Bill Moseley mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
