I don't understand your issue with the stack size.  Yes, content_get() is
deeply recursive, but each stack frame is only 52 bytes.  What workstation
these days can't handle 100K or more recursions of a 52-byte stack frame?

Content is stored as a sequence of deltas.  So the extraction algorithm
is inherently recursive.  We could switch to using a loop and store the
recursion information in memory obtained from the heap.  But what does
that really accomplish, other than making the code more obtuse.

We've not had performance issues with rebuild before.  This suggests that
your repository has a different structure than what we have seen in the
past.  Can we clone a copy of your repository for further study, so that
we can get a better grip on the source of your performance problem?