Don't burn 2k of stack on every iconv, use the heap when it's a slow call.

[Andrew Bartlett]

On Wed, 2011-03-30 at 20:24 -0700, Jeremy Allison wrote:
> On Thu, Mar 31, 2011 at 01:40:30PM +1100, Andrew Bartlett wrote:
> > On Thu, 2011-03-31 at 04:10 +0200, Jeremy Allison wrote:
> > > The branch, master has been updated
> > >        via  21193c8 Don't burn 2k of stack on every iconv, use the heap when it's a slow call.
> > >        via  f9a2f4f Fix bug #7996 - sgid bit lost on folder rename.
> > >        via  cf5ed92 SMBTA: make vfs_smb_traffic_analyzer aware of the sendfile and recvfile functionality and store the results as common read/write results.
> > >       from  b3ffcf8 lib/util/charset smb_panic() on incorrect use of strlen_m_ext
> > > 
> > > http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
> > > 
> > > 
> > > - Log -----------------------------------------------------------------
> > > commit 21193c8eeba6d03f680ad34acbbb4cff14d87809
> > > Author: Jeremy Allison <jra at samba.org>
> > > Date:   Wed Mar 30 18:13:05 2011 -0700
> > > 
> > >     Don't burn 2k of stack on every iconv, use the heap when it's a slow call.
> > >     
> > >     Autobuild-User: Jeremy Allison <jra at samba.org>
> > >     Autobuild-Date: Thu Mar 31 04:09:09 CEST 2011 on sn-devel-104
> > 
> > I'm intrigued.  Why is using 2k of stack a problem?  Isn't it the
> > fastest memory we can get?
> 
> Yes, but it's a *slow* path :-). 

I agree it's the slow path, but we hit it rather often (every umlaut
etc).  

> The fast path is calling the
> "direct" conversions, and as the code was written (depending
> on how clever the compiler is) it would allocate 2k off the
> stack every time the fast path was called (and free again
> of course), even though the fast path doesn't use it at
> all. Once we're going down the slow path I don't care so
> much about speed of having to do the extra allocation.

It just seemed like a really weird micro-optimisation.  You couldn't
just move the stack variable around?

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.