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

[Jeremy Allison]

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 :-). 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.

I'm trying to help reduce our memory usage, so this seemed
like a quick fix (having said that I missed free'ing the
memory in the error code paths, I have a fix cooking in autobuild
that will fix that :-).

I *hate* the : "if (xxxx) return YYYY" code pattern - if I don't see the
{ and } braces on different lines I can easily miss the return
statement (which I did here).

Jeremy.