perl-unicode

Re: Encode; Should we aggregate all EUCs?

2002-02-06 04:18:42
On Wed, Feb 06, 2002 at 09:59:44AM +0000, Nick Ing-Simmons wrote:
Nicholas Clark <nick(_at_)unfortu(_dot_)net> writes:
On Tue, Feb 05, 2002 at 04:29:34PM +0000, Nick Ing-Simmons wrote:
If I throw jis208.enc into the pot, then without -O it is 12s
and with -O approx 4 minutes for a trivial saving.

Whatever is default on 14550 didn't make a very nice noise while compiling

Aargh. I meant 14566. I read the wrong directory name.
I built 14566 last night on FreeBSD 4.5
I built 14550 a couple of days ago on FreeBSD 4.5 RC

on my FreeBSD box. Load average was 0.11, and one of the disks was thrashing
a lot. [Unfortunately I have upgraded to hard disks without LED jumpers, so
I can no longer use the front panel blinkenlights to say whether it harassing
the source directory, /tmp, swap or /usr]

Maybe I should figure out how vmstat works, but I have my suspicion that it's
hammering the machine in the wrong way, and maybe it could trade using more
memory for more less disk access in order to compile faster.
[Then again, more memory => swap => disks, and as best I can tell on FreeBSD
less memory => free memory used as extra disk buffers, so the OS is doing its
best however you config things]. Or am I barking up the wrong tree?

That version would have been doing substring search on on EUC_JP.
There are some large hashes - but I have not had a problem on my machines
(but even the laptop has 192M).

This machine has 16M RAM :-)
It's been cobbled together from freebies.

14564 will stop doing the search - but perhaps will use slightly more memory
as a result.

So this what I was building last night. Sorry about the confusion.

[not sure if editing messages on the outgoing mailspool works :-)
Rebuilding reveals that miniperl is swapping like crazy. Not surprising with
only 16M RAM.]
 
Nicholas Clark
-- 
EMCFT http://www.ccl4.org/~nick/CV.html