Hi Adam, not much time to reply. Not much time to get involved soon. Quick reply.
Adam Kennedy wrote: > If anyone wants to investigate some kind of custom Wx loader, it might > let us save as much as 5-10meg per thread, which would mean a 15-30meg > memory reduction in Padre overall, and double or triple the thread > spawn time (which might get the threads fast enough to remove the need > to pre-spawn a bunch of threads, removing another third of a second > from the startup time. > > It's a job there if anyone would like it. Once somebody figured out a general idea how to do that, I'm confident Mattia would be willing to accept patches or ideas. He's been remarkably open to my suggestion of splitting out Wx::Event. > Alternatively, the upstream and downstream communication channels are > potentially pluggable under the new model, and the tasks are designed > to support moving up or down via any channel that can handle a string. I sent a notice to Adam about my new wrapper of the 0MQ message passing library. It works sort of like Unix sockets, and supports various transport layers including one that is visible only from the application itself. The memory hit of loading the module is currently <1M. Maybe it could be reduced. If I had the time to flesh out the docs, write an Alien::ZeroMQ, and do more testing, this might be a good candidate. The code is on github. Search for ZeroMQ. > So one alternative would be for someone to rewrite the upstream > channel to use unix sockets or shared memory and signals, or some > other method that doesn't require Wx at all. See above. > This would allow us to evade Wx entirely when we spawn the master > thread, which would save almost everything other than the Perl core, > and the core platform of Padre::Constant, File::HomeDir, File::Spec > and a few other minor friends. > > I think either of these options represents the next logical step in > making Padre threads suck faster. The ZeroMQ communication is quite fast, too. The slowest bit would be serialization with Storable. My tests of the Perl wrapper showed a latency of ~40us and a core2core throughput of 9Gigabit/s on a laptop. This 0MQ wrapper thing is a Saturday afternoon experiment of mine, so YMMV. > If you are interesting in some performance hacking, either should be > interesting. > > As an aside, if you can solve the non-TCP socket listener problem > cross platform, we can also upgrade the single instance server to use > the same code, which would let the Debian people enable it by default > and allow single instances to automatically handle multiple Padres > running from multiple places. This should be doable with 0MQ. Cheers, Steffen _______________________________________________ Padre-dev mailing list Padre-dev@perlide.org http://mail.perlide.org/mailman/listinfo/padre-dev
