[19220] in Kerberos_V5_Development
Re: C99 Features
daemon@ATHENA.MIT.EDU (Benjamin Kaduk)
Sat Jun 20 15:11:20 2015
Date: Sat, 20 Jun 2015 15:11:03 -0400 (EDT)
From: Benjamin Kaduk <kaduk@mit.edu>
To: Nathaniel McCallum <npmccallum@redhat.com>
In-Reply-To: <20150619191857.GI6117@localhost>
Message-ID: <alpine.GSO.1.10.1506201506110.22210@multics.mit.edu>
MIME-Version: 1.0
Cc: Nico Williams <nico@cryptonector.com>, "'krbdev@mit.edu'" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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.)
-Ben
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
