Re: [wxperl-users] Handling a large zoomable image (world map)

[Donovan A. <al...@Zo...>]

I am using POE, Wx and POE::Loop::Wx in a production application. =20
=20
POE is pretty cool, but my feelings on it are a mixed bag. =20
=20
Part of my app samples input from digital & analog IO hardware, and I =
had to break that component into it's own app because of decreased =
resolution on poe events in the kernel when using POE::Loop::Wx.
=20
Simply removing the POE::Loop::Wx from this second app gave me back =
0.3-0.5 seconds or so in every second for session events.  It may be =
simple enough to tweak with the timing in the loop or it may simply be =
that processing the Wx events is taking a rather long time (which might =
be able to be solved by breaking a function into more parts), but I =
haven't looked very deeply into it.
=20
There are both pros and cons for POE (as with any system).  I don't have =
a ton of time right now to go into an in depth analysis for you, but =
since the pros are well known, the few important cons/considerations =
that I perceive are:
=20
1> POE will not take advantage of multiple processors and given modern =
processors, this could be a big deal for your code.
=20
2> On a similar note, since it is a single process, you can't take =
advantage of the time spent reading a file (low CPU use) to get =
something else done. =20
=20
3> POE is a pretty complicated framework, which given all it does is =
understandable, but depending on your project, it may be less =
complicated to use threads, threads::shared, and the Event module. =20
=20
4> Since nothing is running in parallel, you have to chop your time =
consuming functions into smaller processing units and at the end of =
"middle units" (forgot the term POE uses), you have to issue a call to =
POE to add the next unit call on the queue.
=20
This is a serious commitment to POE (at least without careful design - =
and maybe not even then) as moving to some other model later becomes =
much more difficult (as opposed to say, using the "forks" module and =
threads interchangeably).
=20
5> Related to the last con, is that you may find yourself reinventing =
wheels (hoho - POE humor), since any CPAN module you use may ruin your =
day and need to be rewritten to do things the POE way.  And if you think =
I jest, look at CPAN's POE modules...it is very much a lot of CPAN =
modules wrapped or modified for POE.
=20
After reading all this, it should become clear that the best solution =
overall would be to use POE with threads.  Well, officially threads and =
POE are not compatible (the CPAN POE threads module is using the old =
perl threads and was really just an experiment) and unofficially it is =
doable, but at such a high memory overhead that it is not realistic. =20
=20
Now, all this being said, POE does what it says on the tin, the project =
your proposing is probably doable with it and it is possible to use POE =
+ Wx for production quality product (as I have done and I believe at =
least someone else has - the devs of POE::Loop::Wx), but you might =
consider doing some serious homework on this first.
=20
Wow...that was longer than intended...lol.

________________________________

From: Ed W [mailto:li...@wi...]
Sent: Wed 6/28/2006 2:07 AM
To: Eriam Schaffter
Cc: Donovan Allen; Jouke Visser; wxp...@li...
Subject: Re: [wxperl-users] Handling a large zoomable image (world map)


Eriam Schaffter wrote:=20

	Le Mer 28 juin 2006 1:20, Donovan Allen a =E9crit :
	 =20

		(in a thread
		perhaps?)
		   =20

	May I suggest POE ?
=09
	I think that would be a perfect fit for this situation !
=09
	You can have a look at POE::Loop::Wx
	 =20


POE is a great suggestion and I have played with it a little already.  =
Actually my first instinct was NOT to use POE on the client end of this =
system (mainly win32) because on the surface it looked as though POE =
might be quite slow?

The application also acts as a network proxy for some other network =
stuff and it would be useful to have it all in one exe process.  Anyone =
got any real world statistics on whether POE is slow and heavy, or =
decently speedy in the real world?

Thanks for all the suggestions so far.  For sure the double viewport =
suggestion is what I was heading towards, but the implementation wasn't =
so clear in my mind until you paraphrased the algorithm so neatly.  =
Thanks

Ed W