Under the new Task 2.0 API we have a much much better chance of getting a really lean slave driver model working.
The basic idea is that we should load a minimalist subset of Wx before spawning the master thread, just enough to emit messages from the child thread back to the parent. There's already some provision in Wx for this, as you can load Wx::Event (500k memory cost) without needing to load all of Wx (9meg memory cost) or Padre::Wx (an extra 4meg on top of Wx). Unfortunately, the new thread code can't survive on Wx::Event alone. I need Wx::Event + Wx::PlThreadEvent->new + (unfortunately) ->AddPendingEvent support or it's equivalent. Enough code to inject a thread event into Wx. Ideally I'd like to be loading a lot less than the entire 10+ meg of Wx just to emit this event. 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. 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. 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. 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. 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. Adam K _______________________________________________ Padre-dev mailing list Padre-dev@perlide.org http://mail.perlide.org/mailman/listinfo/padre-dev
