On Tue, 1 Jan 2008 18:54:40 -0800 Eric Wilhelm <[EMAIL PROTECTED]> wrote:
Hi, > I've been playing with pperl (MST's persistent perl ala FastCGI) and > entertaining the idea of preloading Wx (and an application's modules) > to reduce startup time and/or make a test suite run faster. > > I've gotten as far as determining that Wx::Load() seems to consume about > half of the ~0.2s startup time of a simple 'use Wx()' and that any sort > of forking after Wx::Load() is a no-go (I'm guessing that the C code > creates some singletons including "wxTheApp".) I'd say the problem is likely o be the X connection (something akin to what happens if you fork with an open MySQL connection). > Given that a big app like dotReader takes 2s to start, I obviously want > to cut a little deeper than 0.1s ;-) > > Further, the call to constant() in Wx::AUTOLOAD() hangs if I muck around > a bit with breaking the _start() bit in Wx::Mini. A hack-around for > numerical constants seems straightforward, but this will also be > troublesome for preloading any modules which expect to call e.g. > Wx::wxDEFAULT_POSITION() at BEGIN time. Still not exactly sure if this > is workable but I think it might be solved by the preloader faking-up > and holding each reference, then replacing them all after the fork[1]. > > Any thoughts? Has anyone made any similar investigations? > > Mattia, do you think it is even feasible? Does the very thought of it > deeply offend/trouble you? It doesn't neither trouble nor offend me, but I am not sure it is feasible in a reliable way, because all forked processes are going to use the same X connection and if it works it's more by luck than by design. I think the only thing that could work is removing the _start call from Wx.pm and doing it in the child, after the fork. If that works, we can see how to integrate that in wxPerl (I am thinking either of an environment variable PLEASE_PLEASE_DO_NOT_INITIALZE or making the initialization happen only when needed). > [1] I think this would mean that the preloader either has prior > knowledge of the wx build (e.g. a stringwise dump of the constants) or > else the preloader talks to a non-mangled Wx on a pipe, which increases > the preloader startup time. > > How constant are the constants? That is, if wxHORIZONTAL == 4, under > what circumstances would that change? Recompiling wxWidgets? > Recompiling wxPerl? That is, are there any cases where a cache (on a > given box) would need to be expired based on a conditional which > involved anything other than the wx/Wx version numbers plus maybe > the .pm file location? Most constants are statically defined, but event IDs are dynamically allocated, and can change when wxWidgets is recompiled. Regards, Mattia
