Re: Slowdown around 5.0.5-dev-0

[Bart Schaefer <schaefer@brasslantern.com>]

On Oct 13, 10:21am, Sebastian Gniazdowski wrote:
}
} I meant that maybe the numbers yield some optimization strategy.
} I could try to implement it. But maybe there is nothing left to be
} done?

I think we're all out of low-level strategies without completely redoing
the algorithm.  As I noted, it's optimized mostly for space rather than
speed.  Based on your later two emails, we've increased memory footprint
by about 25% in order to get a significant increase in speed, so that is
probably an OK trade-off on most modern hardware.

At this point I think any gains would be found higher up -- calls to
push/pop the heap that aren't necessary, or places [similar to the use
in completion code] where we could replace push/pop with a NEWHEAPS()
block to avoid scanning existing heaps for free space.

For example, the following shows what I mean.  This may be a poor
choice if most functions are small, so I won't suggest committing, but
this is the kind of well-isolated push/pop that might benefit.

diff --git a/Src/exec.c b/Src/exec.c
index bcc8065..b9c40df 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -5067,10 +5067,11 @@ doshfunc(Shfunc shfunc, LinkList doshargs, int noreturnval)
 #ifdef MAX_FUNCTION_DEPTH
     static int funcdepth;
 #endif
+    Heap funcheap;
 
     queue_signals();	/* Lots of memory and global state changes coming */
 
-    pushheap();
+    NEWHEAPS(funcheap) {
 
     oargv0 = NULL;
     obreaks = breaks;
@@ -5290,7 +5291,8 @@ doshfunc(Shfunc shfunc, LinkList doshargs, int noreturnval)
 	numpipestats = oldnumpipestats;
 	memcpy(pipestats, oldpipestats, sizeof(int)*numpipestats);
     }
-    popheap();
+
+    } OLDHEAPS;
 
     unqueue_signals();