kaduk at MIT.EDU
Sat Jun 20 15:11:03 EDT 2015
On Fri, 19 Jun 2015, Nico Williams wrote:
> On Thu, Jun 18, 2015 at 12:24:04AM -0400, Nathaniel McCallum wrote:
> > On Thu, 2015-06-18 at 01:13 +0000, Danilo Almeida wrote:
> > > [...]. Nathaniel, do you have any
> > > performance numbers would help the case for the extra effort (and
> > > potential risk)?
> > Well, take common inner-function heap allocations and turn them into
> > stack allocations. That is a significant performance gain.
> Probably. A decent heap allocator with per-thread magazines ought to be
> good enough in most cases.
I'm not sure I follow what point Nico is trying to make, here. Anyway,
for me, I thought that modern malloc implementations were supposed to be
pretty performant, so that any gains from eliminating calls to malloc
would be lost in the noise relative to the crypto operations involved.
In other words, I'm not convinced that this isn't premature optimization,
as far as claims of performance gains. (There might still be a reason to
prefer VLAs for code simplicity or readability purposes, of course.)
More information about the krbdev