[PATCH] Final removal of lp_posix_pathnames() from the smbd server main code paths.

[Jeremy Allison]

On Wed, Mar 23, 2016 at 12:52:54PM -0500, Scott Lovenberg wrote:
> 
> I haven't had a chance to look over the full set, but I'd be curious
> if anyone has a reasonable estimate (or WAG) on the performance impact
> of this whole set one way or the other.  Nothing sticks out as slow
> (not that my gut instincts on performance characteristics of code are
> ever remotely accurate!), but a nagging voice in the back of my head
> keeps suggesting that this seems like too good of a flexibility trade
> off without a performance impact, clean as the code may be.
> 
> If my past estimates are anything to go by, this is probably actually
> faster with a smaller footprint (deeper stack depth though at first
> glance), but my curiosity overrides my desire to not make myself look
> foolish. ;)

Nope, haven't done any performance work. Not planning to
until we've got this in and correct first :-).

I'm not expecting it to affect anything, as all the
changes are modifying pathname-based ops, which are
notoriouly already the slow ones.

Once the pathname -> handle translation is done,
this becomes the difference between a global function
call vs. an indirection and flag comparison. e.g.

Between lp_posix_pathnames() and (smb_fname->flags & SMB_FILENAME_POSIX_PATHNAMES).

I really doubt you'll be able to split a hair between
them :-).