Robert May wrote:
I've already re-worked the whole constants support (see the archive for this list a couple of months back), and it currently uses a perl hash to hold the constants and do the lookup, but given the potential number of constants in the windows header files I was thinking of implementing a mph solution (and have been playing with Taj Khattra's mph-1.2, which I have ported to compile under MS VC++).
Jeremy White wrote:
Out of curiosity how much faster is a lookup using the mph-1.2 tool set V the perl hash? How much smaller is the mph structure V the perl hash structure?
I have not benchmarked this, but wouldn't expect much difference - although I would expect the mph lookup to be slightly faster as there will be less dereferencing through perl SV's to retrieve the actual value. Speed isn't actually my primary concern, as the lookup only ever happens once per constant - either at compile time if you use the '-inline' pragma or during runtime when the constant is first accessed.
I don't intend to change the implementation that was distributed on this list for a first release (I do intend to reduce the number of constants included), but following up on some other ideas I started to look at how much memory was being used, and even with the 3000 or so constants currently defined the memory usage is not small (perl hashes are not very memory efficient). There are something like 18000 constants defined in the header files included by Win32::GUI - now I'm sure that we don't want all of them, but thats going to make the hash huge.
So, it was my plan to do a later implementation moving the lookup back into XS, using a 'minimal perfect hash' and an efficient C array. The storage for this approach would be something like 8 bytes per constant identifier (string pointer + long value) plus the constant identifier string length (for the constant lookup array), plus the storage for the polynomial values used by the hash function.
In terms of distribution, couldn't we assume that anyone wanting to add a constant would have (or need) the ability to build Win32-GUI from source? In which case, couldn't the hash be built as part of the build process?
Yes, it'd have to be, as the polynomial values change whenever a new constant is added. I was only struggling with whether to distribute the mph source, and have mph.exe built during the build process, or, as we know this module is only for windows, whether to distribute mph.exe. It's not a big issue
Regards, Rob.
