From: Jeremy W. <jez...@ho...> - 2006-03-18 15:29:14
|
>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'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:) 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. Cheers, jez. |