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

Scott Lovenberg scott.lovenberg at gmail.com
Wed Mar 23 18:12:07 UTC 2016

On Wed, Mar 23, 2016 at 12:59 PM, Jeremy Allison <jra at samba.org> wrote:
> 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 :-).

As measured against latency on the wire, I'll call that a solid draw
at worst even on a P4 with a stalled pipeline. :)

Peace and Blessings,

More information about the samba-technical mailing list