(second attempt: pasting UTF8 into a iso8859-1 message or vice versa
or something thoroughly messed up my reply. This time, it should
work out ok. Thanks Stas for pointing this out)
At 13:26 -0800 1/9/04, Stas Bekman wrote:
Elizabeth Mattijsen wrote:
> I'm sure you know my PerlMonks article
I would second Perrin's comment, why use ithreads instead of forking and
perhaps some socket communication. I've tested both fork and threads in a
high performance envorinment, and fork is simply the better choice as
long as lines of code is not your judgement criteria.
Best,
Tom
Thomas S. Br
At 13:26 -0800 1/9/04, Stas Bekman wrote:
Elizabeth Mattijsen wrote:
I'm sure you know my PerlMonks article "Things yuu need to know
before programming Perl ithreads" (
http://www.perlmonks.org/index.pl?node_id=288022 ).
So yes, in general I think you can say that the data copied for
each thread, q
Elizabeth Mattijsen wrote:
At 15:17 -0500 1/9/04, Perrin Harkins wrote:
On Fri, 2004-01-09 at 14:52, Stas Bekman wrote:
We really need more real world benchmarks to make a good judgement.
It's
probably quite certain that the performance is going to be worse if
you spawn
threads, but don't de
On Fri, 2004-01-09 at 16:02, Elizabeth Mattijsen wrote:
> You mean a rewrite of the article? Or more a bullet list of things?
I was thinking of something that briefly makes these points:
- Threads have a higher startup cost.
- Perl is slower when built with threads.
- Threads tend to use more me
At 15:51 -0500 1/9/04, Perrin Harkins wrote:
On Fri, 2004-01-09 at 15:34, Elizabeth Mattijsen wrote:
So yes, in general I think you can say that the data copied for each
thread, quickly dwarves whatever optrees are shared.
Thanks Liz, this is useful data. Maybe we should add something to the
mod
On Fri, 2004-01-09 at 15:34, Elizabeth Mattijsen wrote:
> So yes, in general I think you can say that the data copied for each
> thread, quickly dwarves whatever optrees are shared.
Thanks Liz, this is useful data. Maybe we should add something to the
mod_perl 2 docs that summarizes the current
Perrin Harkins wrote:
On Fri, 2004-01-09 at 14:52, Stas Bekman wrote:
We really need more real world benchmarks to make a good judgement. It's
probably quite certain that the performance is going to be worse if you spawn
threads, but don't deploy the benefits available exclusively to threads
(s
At 15:17 -0500 1/9/04, Perrin Harkins wrote:
On Fri, 2004-01-09 at 14:52, Stas Bekman wrote:
We really need more real world benchmarks to make a good judgement. It's
probably quite certain that the performance is going to be worse
if you spawn
threads, but don't deploy the benefits available ex
On Fri, 2004-01-09 at 14:52, Stas Bekman wrote:
> We really need more real world benchmarks to make a good judgement. It's
> probably quite certain that the performance is going to be worse if you spawn
> threads, but don't deploy the benefits available exclusively to threads
> (shared opcode tr
At 19:36 + 1/9/04, Simon Clewer wrote:
For us the point of ithreads is that you don't have to mess about passing
messages or whatever - all those problems have been solved by the dudes who
wrote the threading module and you and they have given you shared variables
for your convenience.
I h
Perrin Harkins wrote:
On Fri, 2004-01-09 at 04:14, Stas Bekman wrote:
Ah, sorry for chiming in again, it's true regarding the memory, but not that
bad regarding performance. The only real performance overhead is to spawn a
new perl interpreter (which is just terrible if you have many modules
pr
mory usage we it has done everything we want and performs
quickly and reliably.
>
>
> - Original Message -
> From: "Perrin Harkins" <[EMAIL PROTECTED]>
> To: "Simon Clewer" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Friday, Janu
- Original Message -
From: "Simon Clewer" <[EMAIL PROTECTED]>
To: "Stas Bekman" <[EMAIL PROTECTED]>
Sent: Friday, January 09, 2004 11:11 AM
Subject: Re: ithreads with modperl
> In our case Stas is right, there's plenty of processor resources - eve
On Fri, 2004-01-09 at 11:45, Perrin Harkins wrote:
> However, this is 5.6 with
> ithreads that we're talking about
Correction, Simon says they are actually using 5.8.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
On Fri, 2004-01-09 at 04:14, Stas Bekman wrote:
> Ah, sorry for chiming in again, it's true regarding the memory, but not that
> bad regarding performance. The only real performance overhead is to spawn a
> new perl interpreter (which is just terrible if you have many modules
> preloaded), which
Hi Simon,
Simon Clewer wrote
Hi,
We're using ithreads with modperl to run some complicated robots
concurrently ( in a commercial environment ) - there is however an issue.
Huge memory usage ... each ithread uses about 10M of ram ( image of Apache,
image of mod perl and image of our deep
At 01:22 + 1/9/04, Simon Clewer wrote:
We are simply running out of memory, which is sad because we are nowhere
near running out of processor and it grieves me to simply use a bigger
server when it seems that smarter could solve the problem. Other than that
things are working very nicely and th
Hi there,
I'd echo what Perrin has said, but if only for the archives I need to ask:
On Fri, 9 Jan 2004, Simon Clewer wrote:
> [snip] we're using heaps of memory.
>
> Does anybody know how we can reduce the amount of memory we use ? - is there
> some smart way to actually share the images.
The
Perrin Harkins wrote:
On Thu, 2004-01-08 at 20:22, Simon Clewer wrote:
Huge memory usage ... each ithread uses about 10M of ram ( image of Apache,
image of mod perl and image of our deep-link robot ), and as we use 5
ithreads plus the original thread that means that each Apache is using 60 M
and
On Thu, 2004-01-08 at 20:22, Simon Clewer wrote:
> Huge memory usage ... each ithread uses about 10M of ram ( image of Apache,
> image of mod perl and image of our deep-link robot ), and as we use 5
> ithreads plus the original thread that means that each Apache is using 60 M
> and because we trad
Hi,
We're using ithreads with modperl to run some complicated robots
concurrently ( in a commercial environment ) - there is however an issue.
Huge memory usage ... each ithread uses about 10M of ram ( image of Apache,
image of mod perl and image of our deep-link robot ), and as we
22 matches
Mail list logo
