Front page | perl.perl5.porters |
Postings from November 2011
On Thu, Nov 24, 2011 at 7:13 PM, Reini Urban <rurban@x-ray.at> wrote: > On Wed, Nov 23, 2011 at 11:54 AM, Tom Christiansen <tchrist@perl.com> wrote: >> Jesse Luehrs <doy@tozt.net> wrote >> on Wed, 23 Nov 2011 11:27:27 CST: >> >>> Well, if nothing else, it's a potentially unnecessary use of >>> ~500kb/process. >> >> Ouch! That's good enough for me. Well, or used to be. Guido >> recently told the Python folks that having to load 500k of Unicode >> properties to get regexes to work right on Unicode data didn't >> really bother him much, and I tend to agree with him. >> >> Still, most people think nothing of loading in a megabyte of cruft to do >> something just to get some syntactic sugar for already-loaded, built-in >> functionality. > > The problem is not the size, the problem is the time to load and > unload this tables. > It's a big difference to map a precompiled icu<xx>.so into the process space, > or when perl loads their handmade unicode tables, e.g. folding tables > on lc or m///i; > > And then we also have to manually unload them, handling through the > refcounted SV's which is even worse, compared to unmap or forget. Hurts twice. > > Why cannot we just precompile our tables into a XS lib, and access them > not via perl hashes, but pure functional, so its loaded and destroyed fast. > We autogenerate these tables anyway so it should be no big deal. > > I'm not familiar with our implementation and I think that Collate > might partially do such a thing, but the rest? There's a lot of perl data which should > just be a XS without refcounted hashes. Banging on my head. Encode does exactly this. So I guess the ToFold and utf8_heavy tables should be done in a similar fashion, right? -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/Thread Previous | Thread Next