NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Mark Hahn, <hahn@neurocog.lrdc.pitt.edu>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
EPIC Developers say PPI is too slow for an editor (Score:1)
http://sourceforge.net/forum/forum.php?thread_id=1386755&forum_id=258687 [sourceforge.net]
Re:EPIC Developers say PPI is too slow for an edit (Score:1)
And he'd be right. I've said that from the start, although there are some potential techniques for windowing that might help.
PPI would be used in background mode. Parsing and analyzing in a background process and feeding event and feedback objects back into the editor.
The speed problem won't go away until PPI gets 4 times faster than it is now. But the "can accept any old shit" problem is solved now.
Which means we are go for background
Not a leak, a feature of Test::Builder ;-) (Score:1)
I don't believe there's a serious leak anywhere in your 21_exhaustive.t (with or without Test::More), at least that's what valgrind tells me.
I suspect the primary cause of the memory growth you're seeing is a feature (not a leak) of Test::Builder. If you peek at the implementation of Test->ok() in Builder.pm, you'll see it stores information about each test executed, so that it can do its reporting at the end. Storing this information seems to consume around 500 bytes per test.
I stumbled across
/-\