Buffered output to a file is painfully slow
Andrew Whitworth
wknight8111 at gmail.com
Mon Feb 9 20:10:26 UTC 2009
On Mon, Feb 9, 2009 at 2:50 PM, chromatic <chromatic at wgz.org> wrote:
> On Monday 09 February 2009 11:21:52 Andrew Whitworth wrote:
>
>> On a tangential matter, maybe we need to consider changing "puts" to
>> be a VTABLE instead of a METHOD?
>
> No. We have to fix PCCINVOKE. Ideally, we'll excise it from the system
> entirely. Every time we call into the runloop again from C, we lose.
>
> The problem here, as usual, is that we have too much code written in C.
That's fair, but operations on PMCs that are common enough really
could be VTABLEs. Another discussion for another day.
>> I still can't really understand where all these PMCs are coming from.
>
> Invoking a PMC from C requires generating call signatures and integer arrays.
That's what I really don't understand, why do we need to generate so
many complex data items in order to invoke a single subroutine? The
whole operation should be possible with a fraction of the data
shuffling that we do currently. It's not just PMCs that we're
creating, either. There are lots of little structures created here and
there that aren't GCable. We need a serious overhaul of these
mechanisms to get this right, sooner rather then later.
>> Looking at the generated C code for the puts method, I can immediately
>> see a few things that are suspect, which brings a lot of questions to
>> mind: Why are we generating a _params_sig PMC here it seems to serve
>> no purpose whatsoever? Why are we creating a _returns_sig too? Don't
>> we have the signature for the method already generated as part of
>> Parrot_PCCINVOKE? It doesn't look like the _params_sig PMC is actually
>> being used anywhere either. Also, why do we create a RetContinuation
>> PMC here, what is it's purpose? Parrot_PCCINVOKE, and variants, create
>> a new context for the method when it's called, although
>> NCI.pmc:invoke() doesn't. So in some cases we appear to be creating
>> two contexts for a method call instead of just one.
>
> We might half the amount of garbage created here by being smarter about this,
> but that's the calling conventions branch, and we're blocked on optimizing
> this until we can unify this code.
Give me a priority task and I'll work on it. If unifying NCI/PIR
calling conventions is high-priority, then I'll get started on that
ASAP.
> Sure, but that's going to improve this benchmark by no more than 20%. The
> real solution is not to perform expensive operations, not to make it cheaper
> to clean up after sloppy, expensive operations.
Every little bit helps :). You're right of course, we shouldn't be
prematurely optimizing our GC for a particular resource usage profile
when there are a lot of things in that profile that need to be
changed.
--Andrew Whitworth
More information about the parrot-dev
mailing list