Front page | perl.perl5.porters |
Postings from December 2016
On Mon, Dec 26, 2016 at 10:44 PM, Dave Mitchell <davem@iabyn.com> wrote: > On Mon, Dec 26, 2016 at 10:18:05PM +0100, demerphq wrote: > > An obvious solution to this would be to refcount the stack. However > > even if we assume this is possible (I am doubtful), it would probably > > be slow. I seem to recall that MS did some studies with VB and > > refcount manipulation of stack arguments can account for 25% of run > > time, which is why dotNet is garbage collected. > > But in practice large chunks of pp code mortalise the values they push on > the stack to make them last long enough to be usable for the next op, but > without leaking. So we normally encounter the cost of manipulating the > ref count anyway, with the added costs of checking/extending the mortals > stack as well as the args stack, and pushing the SVs onto both stacks. > > So making the args stack ref counted would quite likely be a net > performance gain (assuming we got rid of the now superfluous > mortalisation), in addition to fixing all the bugs. > I also tend to think less mortalization will help performance, but wouldn't dare making predictions on gains and losses until we can measure this. > The insanely difficult bit is that we currently have nearly 30K lines of > code in the pp functions which all assume they can just do SP-- or SP -= n > without worrying about what's on the stack. Or to croak with rubbish still > in the stack, We would either have to review and modifiy *all* that code, > or come up with a scheme whereby individual pp functions can be marked as > "refcount ready" > I imagined we'd have a bunch of macros that communicate intent, and those get translated to the right thing depending on whether or not refcounted stack is enabled. LeonThread Previous | Thread Next