The open opcode

Andrew Whitworth wknight8111 at gmail.com
Fri Apr 23 11:24:28 UTC 2010


In the case of the open operation, avoiding the PCC call is probably
not a huge savings. Open is not called often enough to make a huge
difference either way. Operations like read/write are both called far
more often so the saves there really do add up over time. I have no
problem making the uncommon case more expensive if it gives us better
security utility. I'm sure we could find performance savings elsewhere
in the IO subsystem to make up for it.

--Andrew Whitworth



On Fri, Apr 23, 2010 at 4:30 AM, Allison Randal <allison at parrot.org> wrote:
> On 4/23/10 3:17 AM, Geoffrey Broadwell wrote:
>>
>> Honest question: How did this ever turn up as a performance issue?  Was
>> this a response to performance problems before the PCC
>> refactoring/optimization?
>>
>> I'm trying to imagine a case (even a completely contrived one) in which
>> the addition of a PCC call during the file open operation becomes a
>> bottleneck, and I'm afraid I'm failing, unless I've grossly
>> underestimated the cost of a PCC call in my calculations ....
>
> I was surprised too. Before the I/O refactor year before last, chromatic and
> I had a running gag about I/O optimizations: "The slowest thing about I/O
> is... I/O."
>
> Turns out, that's not true. If you load I/O down with a pile of PCC method
> invocations, you can slow it down. Substantially.
>
> Allison
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>


More information about the parrot-dev mailing list