[19217] in Kerberos_V5_Development
Re: C99 Features
daemon@ATHENA.MIT.EDU (Nico Williams)
Fri Jun 19 15:19:10 2015
Date: Fri, 19 Jun 2015 14:18:58 -0500
From: Nico Williams <nico@cryptonector.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Message-ID: <20150619191857.GI6117@localhost>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1434601444.15953.9.camel@redhat.com>
Cc: Danilo Almeida <dalmeida@mit.edu>, "'krbdev@mit.edu'" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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.
> VLAs make perfect sense for operations like fx_cf2 where you need to
> mix two keys together using intermediary buffers. If you validate that
> the input keys are valid types then you know that the buffer for that
> type will be a sensible size to put on the stack. This eliminates two
> unnecessary heap allocations.
Yes, but then, those keys are small. So VLAs/alloca() here are fine.
alloca() has been around for a long time, no? You don't need C99 to use
alloca().
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
