The improvements remove about 0.2 secs. on the Acer One.
In this particular instance, thee cost for mapping and unmapping seems to be
comparable to ip, but on the whole it seems to speed up the process quite a
bit.
Dan Bron's nub and ip functions are faster than my code, proving again that
tacit programming is faster. The difference is not dramatic, but I guess if
one is to be as efficient as possible in J, then tacit is the way to go,
within reason of course.
The nub function should be:
nub =: ~.@:({."0 <~.@:(%7B.%220> 1 ~(i."1&' '))
because I need to ignore all characters from the first blank on each IP
address, in case the IP is shorter than 14 characters and is followed by
something else.
With these changes J gains an additionnal speed advantage over the original
C code. But to be fair, I should mention that C becomes at least as fast as
J if you take the extra step of using mapped files in your C code.
On Fri, Oct 3, 2008 at 12:50 PM, Raul Miller <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 3, 2008 at 11:41 AM, Dan Bron <[EMAIL PROTECTED]> wrote:
> > While this is a solution, it simply abtracts the entanglement into a
> reusable piece of code.
> > It is essentially identical to the original "fetch".
> >
> > If you'll recall, the problem I was illustrating with that verb was that
> it wasn't possible to
> > time the file-reading and data-processing aspects independently, without
> re-writing my code.
> >
> > That problem persists here.
>
> A part of the problem is that this access mechanism is designed to be
> efficient.
>
> The operating system will only retrieve data from the file when its
> block is referenced.
> And, even there, it might or might not have to retrieve the data from
> disk -- there's
> multiple layers of caching.
>
> So, hypothetically speaking, # onfile 'help.htm' might not read anything
> from
> disk. Or maybe the first "block" would be retrieved. Or maybe something
> else.
>
> On the other hand, if you are looking at repeatable times, then you can
> allow whatever caching exists to just happen, and you can compare the
> operation against the file with the operation against a similarly sized
> chunk of data. Or you could cold reboot between each test, to ensure that
> you had cleared any cache (you might need to power off, however, to
> ensure that there's no hardware mechanism caching data across reboots).
>
> Note also that many of these mechanisms would also apply to 1!:1, but
> 1!:1 might have enough overhead that you could neglect those mechanisms?
>
> --
> Raul
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
