Robert wrote:
> The difference is not dramatic
Interesting, it was in my tests. However, the speedup is more a function of
the number of IPs (i.e. matches found by 'rhost=
'&E. ) than the total size of the file, and obviously my test data differs
from yours.
> 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.
Ah, of course. Didn't think of that. Given this constraint, I believe the
majority of the time is going to be spent in trimming
and reassembling this array. (Again, provided your list of IPs is large.)
One potential optimization would avoid trimming the large list of IPs. Take
the nub of the "dirty list", then trim, then nub
again. Trimming and reassembling this (presumably) smaller array might save
you more than the cost of the second nub.
Another potential optimization (which again improves with the size of the IP
list) is to avoid manifesting the entire addition
table. Instead of
ip =: ] {~ I.@:E. +/ '255.255.255.255' (+i.)&#~ [
you could try
ip =: ] ];.0~ (#'255.255.255.255') ,:"0/~ #@:[ + I.@:E.
I haven't tested any of these proposed changes, so they may be broken, buggy,
or even slower than the current solution. And
improvements, if any, are likely to be even less dramatic than the first round.
Also, I believe your solution currently completes in less than a second, which
is not such a burden. So it might not be worth
rewriting, particularly since optimized code tends to be less familiar (hence,
less readable/maintainable).
The real value of J in this instance is that it's (A) [more than] competitive
with the equivalent C code and (B) it was much
faster to write (correct?) and very likely easier to change. The more time
spent optimizing, the smaller the benefit of (B).
> to be as efficient as possible in J, then tacit is the way to go
Since one of my two optimizations was a non-starter, the entire speedup can be
attributed to the replacement of I. x E. y with
x I.@:E. y . That construct is supported by special code, and happens to be
tacit. So in this case the efficiencies were a
result of using special code, rather than tacit code, per se.
-Dan
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
