On Wed, Dec 11, 2002 at 09:25:15AM +0000, David Cantrell wrote: > For one of my crack-induced ideas, I have a humungous number of objects > floating around, which need to call methods on each other. When a method > is called on object $a, it may well then go on to call methods on $b and > $c, which call methods on $d, and on $e, $f and $a, and so on. Yes, there > can be loops in here but the system will eventually settle down to a new > steady state. I could, of course, call each method in turn, waiting for it > to finish, before going on to the next, but it would be better if $a could > poke $b and $c in parallel, which would then poke $d, $e, $f and $a in > parallel, and so on. These methods have no useful return values.
Surely it depends what the methods are doing. If they're purely CPU or memory-intensive then threading will probably make it slower unless you have lots of CPUs. If they do lots of disk I/O then spawning multiple (kernel) threads or processes may help. POE will not, since disk I/O is generally blocking anyhow. If they do lots of network things (like, say, getting web pages) then POE or similar is probably the way to go. I like the Event module, but then I also like re-inventing the POE::Wheel. Interesting paper about scalable I/O strategies: http://www.kegel.com/c10k.html
