From: Robert M. <rm...@po...> - 2006-05-01 20:51:30
|
I've been re-visiting the code I wrote some months ago, and discussed here, to provide us with a faster and more readily extensible way of having access to all the Win32 API constants that we might need. This is long. Sorry. The main purpose of this mail is to document the research and test results that I have from the last week, but first I'd like to write down what I intend to change in Win32::GUI itself: Proposal for change in Win32::GUI ================================= - Win32::GUI::Constants will become the module that supports constants. It will be possible for end-users to use this module directly, or to pass the same export requests to Win32::GUI directly (as we previously discussed). So either use Win32::GUI qw(export_list); or use Win32::GUI::Constants qw(export_list); will have the same behaviour with respect to exporting constants. - I will deprecate the way Win32::GUI currently exports over 300 constants without being explicitly asked. In the 1.04 release use Win32::GUI; will still export the same constants, but will generated a 'deprecated' warning, including instructions about the correct syntax to use. - I will deprecate calling the Win32::GUI::constant() function directly. Again, it will continue to work in the 1.04 release and generate a 'deprecated' warning. - There will need to be a small XS based constant lookup function within Win32::GUI to support the small number of places that Win32::GUI itself currently uses Win32::GUI::constant() - only to lookup the Win32__GUI__ constants, which don't belong in the new Win32::GUI::Constants package anyway. Changes to Win32::GUI::Constants ================================ The last time we talked about this I had implemented Win32::GUI::Constants in pure perl, basing the lookup on a perl hash. I had reservations about the memory usage and speed of this implementation, and have done some further research to look at the reality. It turns out that the perl hash is *very* fast, but uses a lot of memory. I have looked into 3 alternative hashing strategies, all implemented in XS (as an aside, the overhead of calling an XS function that does nothing compares very favourably with a perl hash lookup, and so previous concerns that I had about XS calls being slow seem unfounded): Strategy 1: non-order preserving minimal perfect hash, based on the algorithm and C source from http://burtleburtle.net/bob/hash/perfect.html I will call this the 'Perfect' algorithm Strategy 2: non-order preserving (non-minimal) perfect hash, generated using gperf: http://gnuwin32.sourceforge.net/packages/gperf.htm I will call this the 'Gperf' algorithm. Strategy 3: Order-preserving minimal perfect hash. based on the code from: http://www.ibiblio.org/pub/Linux/devel/lang/c/mph-1.2.tar.gz I will call this the 'MPH' algorithm The original ladder-of-if's found in GUI_constants.cpp will be called the 'Win32::GUI' algorithm The current hash implementation discussed here for Win32::GUI::Constants will be called the 'Hash' algorithm. There are a number of results to share. It has been difficult to ensure that I am really comparing like-with-like; where there appears to be data points missing, it is because I have not found a satisfactory (read quick enough) way of generating these points, and I feel that I have enough knowledge of the algorithms to extrapolate further behaviour. All performance tests were made on Win98, ActiveState Perl 5.8.7 (build 813), using the Benchmark module's cmpthese() function and the :hireswallclock pragma specified. The performance figures are measured while retrieving every constant - this will give us a good average figure. I have made no attempt to benchmark worst and best case figures. The figures are from a lightly loaded 750Mhz PIII machine, and tests were repeated to ensure consistancy - in all case a maximum vriation of +/-5% was achieved. All XS parts were compiled with MS VC++ 6 compiler with the -O flag set Unless otherwise stated all memory figures were obtained using WinTop (from Microsoft's Windows 95 kernel toys distribution) - Comparison of existing Win32::GUI and new Hash algorithms ----------------------------------------------------------- No memory comparison available, as it's too hard to separate out the constant code from Win32::GUI. Performance benchmarks for retrieving all 364 constants: Rate Win32::GUI Hash Win32::GUI 691/s -- -58% Hash 1653/s 139% -- showing the new hash implementation to be well over twice as fast as the existing implementation, and we know that the existing linear search performed by Win32::GUI will get slower as the number of constants increases. - Comparison of Hash, Perfect, Gperf and MPH algorithms ------------------------------------------------------- Performance comparisons, retrieving 1588 constants: Rate MPH Gperf Perfect Hash MPH 182/s -- -0% -13% -40% Gperf 183/s 0% -- -13% -40% Perfect 211/s 15% 15% -- -30% Hash 303/s 66% 66% 44% -- Memory usage comparisons, as deltas from a baseline, having loaded the module (and nothing else) over and above the baseline. It should be noted that a number of the generation tools (most notably gperf) have many options for trading off memory usage for speed. In general I was aiming for better memory usage, as it quickly became clear that if memory is not an issue then the Hash alogithm wins. All figures in Kbytes: Hash Perfect Gperf MPH DLL Size 0 57 94 78 Memory Usage 416 160 164 176 (delta over common baseline) I was a little surprised at the memory overhead of the Hash algorithm, as Devel::Size estimated the hash size at a little over 88Kbytes, but loading the module with out populating the hash clearly showed that nearly all of the 416Kbytes (all bar about 50Kbytes) was attributable to the hash. On the basis of these numbers I am going to choose the 'Perfect' algorithm to implement the Win32::GUI::Constants module: it's performance is clearly better than what we have today, whilst using well under half the memory footprint of the Hash algorithm. Regards, Rob. |
From: Reini U. <ru...@x-...> - 2006-05-02 07:34:49
|
2006/5/1, Robert May <rm...@po...>: > I have looked into 3 alternative hashing strategies, all implemented in > XS (as an aside, the overhead of calling an XS function that does > nothing compares very favourably with a perl hash lookup, and so > previous concerns that I had about XS calls being slow seem unfounded): > > Strategy 1: non-order preserving minimal perfect hash, based on the > algorithm and C source from > http://burtleburtle.net/bob/hash/perfect.html I will call this the > 'Perfect' algorithm > > Strategy 2: non-order preserving (non-minimal) perfect hash, generated > using gperf: http://gnuwin32.sourceforge.net/packages/gperf.htm I will > call this the 'Gperf' algorithm. > > Strategy 3: Order-preserving minimal perfect hash. based on the code > from: http://www.ibiblio.org/pub/Linux/devel/lang/c/mph-1.2.tar.gz I > will call this the 'MPH' algorithm > > The original ladder-of-if's found in GUI_constants.cpp will be called > the 'Win32::GUI' algorithm > > The current hash implementation discussed here for Win32::GUI::Constants > will be called the 'Hash' algorithm. Good to see that finally gperf found its successors: Perfect and MPH. gperf is completely insatisfactory not finding a solution, esp. when you know that it comes from a common lisp programmer. http://burtleburtle.net/bob/hash/perfect.html looks fine. Go for it. But don't forget to support EXPORT tag groups and wildcards. use Win32::GUI::Constants qw(!/^T/); #don't export T* constants -- Reini |
From: Robert M. <rm...@po...> - 2006-05-02 19:20:24
|
Reini Urban wrote: > 2006/5/1, Robert May <rm...@po...>: [stuff about different hashing options] > Good to see that finally gperf found its successors: Perfect and MPH. > gperf is completely insatisfactory not finding a solution, esp. when > you know that it comes from a common lisp programmer. I didn't have problems with gperf not finding solutions, but to be fast it needed to generate HUGE, sparse lookup tables (about 33,000 entries for my 1588 constants). In order to make the lookup table smaller, I had to go for options that cause it to use binary searches or large switch statements, which make its output slower. > http://burtleburtle.net/bob/hash/perfect.html looks fine. Go for it. I've got a bit of work to do to the original code to get it to fit into a sensible build process, but I'm most of the way there. I intend to keep the generated code cleanly separated from the rest of the module, making it easy to swap algorithms later if we find other solutions or the existing ones are improved. > But don't forget to support EXPORT tag groups and wildcards. > use Win32::GUI::Constants qw(!/^T/); #don't export T* constants Already there - I'll be supporting the full Exporter.pm syntax (but I'm not actually using Exporter, as it has some pretty large memory overheads itself). Regards, Rob. |
From: darrik <da...@my...> - 2006-05-09 01:06:55
|
Greetings. My name is Darrik Mazey. I've been a (mostly reading, sometimes posting) member of the win32-gui-users list since early 2003. I've been using Win32::GUI for quite some time and thought I'd try and contribute a little of my spare time back into the project. The project has made leaps and bounds since the 0.665 version, and it's my hope that I can be of some use. In that spirit I have recently joined the hackers list as well. I exported the cvs source and began to familiarize myself with it. Once I feel comfortable with that, I will try and work on either some low priority bugs or feature requests that no one has taken up yet. If anyone has any suggestions, tips, unstated best practices, advice, or whatever, I'd welcome and greatly appreciate it. In a brief About Me, I just want to state that I've been programming for many years (C, C++, but my love is for Perl), but I have never contributed to a sourceforge project before. Hopefully my inexperience in this respect will be forgiven, and I will do my absolute best to observe the standards and practices to which you are accustomed, and also welcome any pointers, critiques, and helpful criticism you can send my way. Regards, Darrik |
From: Jeremy W. <jez...@ho...> - 2006-05-09 16:18:04
|
Hi, >I exported the cvs source and began to familiarize myself with it. Once >I feel comfortable with that, I will try and work on either some low >priority bugs or feature requests that no one has taken up yet. If >anyone has any suggestions, tips, unstated best practices, advice, or >whatever, I'd welcome and greatly appreciate it. If you haven't already done so, create a sourceforge ID, and drop an email to Rob May who will give you permissions to check in code. As for advice...For me the biggest learning curve was perl XS - the perl documentation isn't ideal (for a starting point see perlxs and perlapi) - the best resource I've found is the book Extending and Embedding Perl by Tim Jenness and Simon Conzens. Most of the XS code for win32-GUI is straightforward. Choosing a low priority bug or feature requests is a good way to start - if it's just about learning, just play and ask questions:) If you think you'll be checking it in at some point, ask the list first as someone else might be working on the same thing. Rob is working on some big chunks of functionality, and some coordination might be required. All the best, and welcome to the team. Regards, jez. |
From: Robert M. <rm...@po...> - 2006-05-14 22:21:43
|
Hi Darrik, Firstly let me apologise for the length of time it's taken me to get back to you, although I see that some of the regulars have already welcomed you into the fold. Also let me thank you for offering some of your time, and I hope that we can make your time spent here worthwhile. I think I've added you to the project as a developer with CVS access - but the sourceforge user interface has its quirks (you'll come to love it), so please let me know if you have any problems. You should also have the correct permissions to administrate tracker items. You'll find documentation on SourceForge to help you get set up, and please call on us here if you need any assistance. I think your plan of picking some "low-priority" items to start to find your way around is a good plan - but please note that the 'priority' assigned in the trackers is fairly arbitrary: most have the default '5'; a couple of items that I though were important to deal with have higher priority, and a few lower. Those with priority '1' have been dealt with, and will be closed when we make the next release. If you can't find anything that you think is suitable for starting with in the trackers, then let me know, and I have a whole list of other items from which I would be happy to select a handful for you to have a look at. Good luck, and welcome on board. Regards, Rob. darrik wrote: > Greetings. My name is Darrik Mazey. I've been a (mostly reading, > sometimes posting) member of the win32-gui-users list since early 2003. > I've been using Win32::GUI for quite some time and thought I'd try and > contribute a little of my spare time back into the project. The project > has made leaps and bounds since the 0.665 version, and it's my hope that > I can be of some use. In that spirit I have recently joined the hackers > list as well. > > I exported the cvs source and began to familiarize myself with it. Once > I feel comfortable with that, I will try and work on either some low > priority bugs or feature requests that no one has taken up yet. If > anyone has any suggestions, tips, unstated best practices, advice, or > whatever, I'd welcome and greatly appreciate it. > > In a brief About Me, I just want to state that I've been programming for > many years (C, C++, but my love is for Perl), but I have never > contributed to a sourceforge project before. Hopefully my inexperience > in this respect will be forgiven, and I will do my absolute best to > observe the standards and practices to which you are accustomed, and > also welcome any pointers, critiques, and helpful criticism you can send > my way. > > Regards, > > Darrik > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Perl-Win32-GUI-Hackers mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers > http://perl-win32-gui.sourceforge.net/ > |
From: darrik <da...@my...> - 2006-05-16 05:08:36
|
Thank you, Robert, Glenn and Jeremy, for making me feel quite welcome. And thank you, Robert, for adding me to the project. I set up ssh and whatnot, so I'm in and ready to go. It was my intent to work on low-priority bugs and feature requests, for familiarity and whatnot, but also to avoid anyone having to take the time to give me direction. However, if there are specific things you have in mind you would like me to look at, I would be more than glad for the direction and will dig into it immediately (or what passes for such in my life). Let me know at your convenience. And again, thanks much for the welcome (as I was a tad nervous). ;) Darrik Robert May wrote: > Hi Darrik, > > Firstly let me apologise for the length of time it's taken me to get > back to you, although I see that some of the regulars have already > welcomed you into the fold. Also let me thank you for offering some of > your time, and I hope that we can make your time spent here worthwhile. > > I think I've added you to the project as a developer with CVS access - > but the sourceforge user interface has its quirks (you'll come to love > it), so please let me know if you have any problems. You should also > have the correct permissions to administrate tracker items. You'll find > documentation on SourceForge to help you get set up, and please call on > us here if you need any assistance. > > I think your plan of picking some "low-priority" items to start to find > your way around is a good plan - but please note that the 'priority' > assigned in the trackers is fairly arbitrary: most have the default > '5'; a couple of items that I though were important to deal with have > higher priority, and a few lower. Those with priority '1' have been > dealt with, and will be closed when we make the next release. If you > can't find anything that you think is suitable for starting with in the > trackers, then let me know, and I have a whole list of other items from > which I would be happy to select a handful for you to have a look at. > > Good luck, and welcome on board. > > Regards, > Rob. |
From: Robert M. <rm...@po...> - 2006-05-16 22:25:32
|
darrik wrote: > And thank you, Robert, for adding me to the project. I set up ssh and > whatnot, so I'm in and ready to go. great. > It was my intent to work on low-priority bugs and feature requests, for > familiarity and whatnot, but also to avoid anyone having to take the > time to give me direction. I'm happy either way, and certainly don't feel the need to give direction at this point. I'd much rather you did what you were comfortable with. My feeling was that there's not much suitable for 'getting started' in the bugs and feature request lists - I think I picked off most of the easy ones when I was finding my way around! > However, if there are specific things you > have in mind you would like me to look at, I would be more than glad for > the direction and will dig into it immediately (or what passes for such > in my life). I've not got much on my own list that I want for the V1.04 release, but a whole load for beyond that. Without us going round in circles, if you want some ideas for things not in the bugs/rfe lists give me a shout. Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/ |