Buffered output to a file is painfully slow

[chromatic]

On Monday 09 February 2009 12:10:26 Andrew Whitworth wrote:

> > 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.

No.  That makes the problem worse.  Please understand this:

*Every time we convert between C and Parrot calling conventions, we throw away 
almost every hope of speed.*

We can't hope for JIT to save us there, because that calling conventions 
conversion barrier *prevents* smart JITting.

We can't hope for clever escape analysis to save us, because that calling 
conventions conversion barrier *prevents* us from knowing if a GCable element 
has escaped the realm of stack-allocation-okay to heap-allocation-essential -- 
unless we somehow instrument and analyze all of the potential C code 
callgraphs to give an idea of whether an element has escaped.

> > 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.

Top priority: get the generated PCCINVOKE headers out of METHODs in the .c 
files generated from .pmc files.  Then we can look at ways to optimize that.

Second priority: refactor all invocations of Subs and Sub-like PMCs to use 
CallSignature PMCs, so we can either prove that that line of thinking is 
horribly flawed and will give us another order of magnitude slowdown, or we 
can optimize it so it's not nearly as expensive.

-- c