develooper Front page | perl.perl5.porters | Postings from November 2011

Re: RFC: Autoloading charnames

Thread Previous | Thread Next
Reini Urban
November 24, 2011 20:35
Re: RFC: Autoloading charnames
Message ID:
On Thu, Nov 24, 2011 at 7:13 PM, Reini Urban <> wrote:
> On Wed, Nov 23, 2011 at 11:54 AM, Tom Christiansen <> wrote:
>> Jesse Luehrs <> 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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About