Front page | perl.perl5.porters |
Postings from December 2009
2009/12/10 karl williamson <public@khwilliamson.com>: > demerphq wrote: >> >> 2009/11/24 karl williamson <public@khwilliamson.com>: >>> >>> Attached is a patch to cut down the frequency of mktables running. It >>> turns >>> out the problem was a combination of both Makefile and mktables. I didn't >>> realize that the files I removed were listed as dependencies in Makefile, >>> so >>> it always thought it was out-of-date, and called mktables. Part of the >>> old >>> code I hadn't changed caused mktables to remove all the files when called >>> with the -makelist option. This code is no longer necessary, so I >>> removed >>> it. >>> >>> I also changed Makefile to always call mktables, to let it decide if it >>> actually should recompile. I just commented it out for easy reversal. >>> The >>> problem is that mktables depends on almost 800 files, located in the To >>> and >>> lib subdirectories, and Makefile doesn't know about them all; and they >>> change from Unicode release to release. I'm assuming mktables.lst was >>> created because of the issues of trying to get them all known by >>> Makefile. >> >> Yes, and also because we used to basically just generate them all, and >> there was no list, we just had dependencies on a few files, and for >> some irritating reason mktables would run like, umm, 6 times on win32. >> And so back in the day it used to regenerate everything each of those >> six times. So i taught it about the list of files and made it more >> intelligent so that it doing things over and over turns into a noop on >> following runs. Please dont make it too slow, in particular certain >> stat calls on win32 are effectively a file open on every file in the >> tree. If you do do that pleasee enable sloppy stat. >> >> cheers, >> Yves >> > I don't know about sloppy stat. But the patch does fix the bug in which > mktables got it wrong about needing to run or not. On my Linux/Vista box > (this year's model) it compiles in under 30 seconds, and now doesn't redo > itself unless it should. Win32 doesnt support the full linux stat interface. In order to determine the nlink (iirc) count on a file on windows the file must be opened and then the calls made to against the open handle. This means that a File::Find on win32 is massively slower than a File::Find on linux, and it is much much worse if the directory being searched is a NTFS share. The sloppy stat variable $^WIN32_SLOPPY_STAT (iirc) will disable the nlink count and make an instant speedup on any directory or file scanning code on windows that uses stat as it no longer needs to open the file to calculate a value that is actually very rarely used in the win32 world. Anyway, thanks for this patch! Sounds great. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next