On Sat, 07 Jan 2006 10:12:40 -0800
"Nicholas Clark via RT" <perlbug-followup@perl.org> wrote:
>Your conclusion about _ not being fast is not valid. The _ handle is
>documented as re-using the last stat test. However, your comparison
>tests are:
>
>> "-d" => '{$r = -d "test"}',
>> "_" => '{stat "test"; $r = -d _}',
>
>"-d" will perform one stat system call and then the -d test, using 1
>perl op. "_" will perform one stat system call and then the -d test,
>using 2 perl ops.
Yes, I know. It just seems a bit odd that the extra operation takes
enough work for the two tests to not be exactly equivalent.
>I feel that your tests are somewhat unfair, in that the calls to Fcntl
>incur subroutine call overhead, whereas your code is all inline.
>
>If I change the tests so that all are calling subroutines:
>then a different pattern emerges.
>
>To me, this suggests that with the constants now inlined inside Fcntl,
>S_ISDIR() now is comparable in speed with an equivalent local
>subroutine.
The point of writing the tests as they were is that each represents how
their methods would be used when speed is an issue. In Fcntl, a sub
call is unavoidable; in the other tests, it's unnecessary.
>Note that the two tests Fcntl and Fcntl_only will be slower than they
>might at first seem, because &Fcntl::S_IFMT is not an inlinable
>constant, so always has to be called:
>
>sub S_IFMT { @_ ? ( $_[0] & _S_IFMT() ) : _S_IFMT() }
Does this serve a useful purpose? With sub calls so expensive, it would
be much better for S_IFMT to be a constant, leaving the masking to the
end users. It's strange for this extra functionality to exist in a
module that's supposed to be a translation of fcntl.h.
Thread Previous
|
Thread Next