Jeremy White wrote:
> Robert May wrote:
NotifyIcon I certainly have on my list of candidates. I haven't
thought much beyond that, but I am hopeful that a restructuring like
this might reduce GUI.xs and GUI.pm to more manageable sizes. I also
want to experiment with moving a lot of the per-control methods from
XS back into perl. There are many methods implemented in XS that do a
single call to SendMessage. By moving them back into perl I don't
think we'll see much of a performance hit (there's still one 'thunk'
between perl and XS, which I suspect to be the largest time overhead),
and will be able to move all such methods to be AUTOLOADed, so we only
take compile time and memory hits if we use them in our apps.
I think we also have to bare in mind that a Win32-GUI app isn't deployed
and run in the same way as a normal perl module/application. Most of the
time a Win32-GUI app is run as an exe produced by PerlApp/Perl2exe/PAR.
Even if the dll is reduced in size by moving out simple sendmessage
calls, we just add bloat to the perl packages which would increase the
size of the exe - even if those functions are never used. OK - if we
split things out into separate packages they shouldn't be included in
the exe - but I'm just wondering if we're making work for ourselves
without any "real" tangible benefits i.e., if it's not broke why "fix it"?
I think there are 2 main uses for Win32::GUI:
(1) Very simple front ends for Windows platforms. For example, consider
the recent request in the users list for implementing a dialog to enter
a text string. When doing simple things like this we shouldn't have to
pull in 3MB of dll plus all the perl code.
(2) The example you give on an app packed with PAR/PerlApp/Perl2exe etc.
Even in this case it would be nice to minimise the amount of stuff
that we need to package up.
I can' speak for PerlApp and Perl2exe, but it is my understanding that
PAR has the ability to determine what methods are used, and only package
up the autoload subs that are required. I am sympathetic to using these
packaging tools, and certainly don't want to do anything that increases
the difficulty of making such exes. Equally I don't want to see their
size increase either. The perl vs. xs split is a difficult call to
make, and one that I am not convinced I know the right answers to yet,
but I do want to experiment with some ideas, and see how the
size/performance trade-offs work.
I'm a little "sensitive" when it comes to memory usage, as one of my
Win32-GUI apps uses 50 meg before it's even done anything - a good chunk
of that is due to Win32-GUI - I use a lot of controls, and think of all
those SV's that are used for each one:) Getting rid of the tied hash
would be a good start:)
Getting rid of the tied hash mechanism is on my list of things to look
at. I think that I do now understand all that it is doing for
Win32::GUI, however, I'm nervous about touching it, as the potential for
introducing memory leaks and destruction problems is very large
(although as currently implemented there are already some problems). I
will get around to looking at this, but it needs care.
I don't think the perl vs. xs issue significantly affects the number of
SV's that will be used per-say.
Assuming you mean the typemap code when you talk about the "thunk" - the
Win32-GUI typemap it's relatively efficient - more so than the "classic"
way of doing a typemap conversion (when you check for the correct
object) - so it'll probably be worth doing some performance testing to
see what (if any) the impact would be.
Not just the typemap. By the 'thunk' (and I think 'thunking' is a
proper perl term) I mean all the stack and variable manipulation that is
required to call into XS - conversion of SV's to C variables and back
has overhead ... Where I'm going here is that we don't want to move
functions/methods that call multiple windows apis from xs back into
perl, as that would leave us with a function that does multiple
perl-xs-perl transitions, rather than a single one.
More work required, and it will happen in time. I hope that it can be a
gradual evolution, during which we learn what works and what doesn't.
Regards,
Rob.
