Dear Alceu,
I don't *think* the overhead of compiling with threads on is a big issue for code that does not use threads. I am open to correction on that of course :-) I do have both a threaded and non-threaded available. Maybe I can test at some point.
I've had to jump thru' hoops to get my *threaded* performance (I mean - in a genuinely threaded application) up to scratch though (bascially reducing the memory footprint per thread) because it clones the environment in the new thread, including loaded modules, and so on. But I do have threaded Perl apps that run with 100's of threads just fine.
But, again, if you don't actually *use* threads, I'm not sure that matters.
Kind regards
Derek.
| [reply] |
Yes, I do recommend that. I haven't run any tests lately, but historically (early v5.8) threaded Perl has been slower than non-threaded Perl even when not using threads.
-sam
| [reply] |
Well, I've narrowed it down to ......
...
langof()
in
Lingua::Identify
Called from
Text::Compare
If I set the lang to 'en' in Text::Compare's get_words() subroutine, it runs at a steady ~24MB on Linux. Of course, the metric is now different, since it's not "correctly" (as if it ever really was) identifying the languages, but for my app that's not really a problem, since I don't care. As long as it doesn't skew the results badly, - and since this isn't the only metric I'm using, it's not looking that bad.
It's main effect is to cause the matches I get back to indicate more similarity than before. And, actually, I'd rather have more false positives - so it doesn't hurt too much.
I'll talk to the Lingua people next I think now....
Thanks for everyone's suggestions.
Kind regards
Derek.
| [reply]
[d/l]
[select] |
| [reply] |