From 4a35c974e97551b1ccbfa41d4c08f0598e3c26aa Mon Sep 17 00:00:00 2001 From: Volker Lendecke Date: Sun, 1 Mar 2009 11:39:44 +0100 Subject: Only copy sharename up from rap_to_pjobid Why?? :-) Another one of the little micro-optimizations that I just came across: If you allocate a variable in a sub-block like the "fstring sharename" in write_file(), gcc even with -O3 will allocate this variable unconditionally on the stack at the beginning of the routine. So with eliminating this fstring we cut 256 bytes of stack in a very hot code path writing to a file. It might make us a bit more cache-friendly. This would probably not be worth a second look if it involved larger code changes, but this one was just too simple to let it pass :-) --- source3/smbd/fileio.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'source3/smbd') diff --git a/source3/smbd/fileio.c b/source3/smbd/fileio.c index a9a97a2d14..adf664b396 100644 --- a/source3/smbd/fileio.c +++ b/source3/smbd/fileio.c @@ -256,10 +256,9 @@ ssize_t write_file(struct smb_request *req, int write_path = -1; if (fsp->print_file) { - fstring sharename; uint32 jobid; - if (!rap_to_pjobid(fsp->rap_print_jobid, sharename, &jobid)) { + if (!rap_to_pjobid(fsp->rap_print_jobid, NULL, &jobid)) { DEBUG(3,("write_file: Unable to map RAP jobid %u to jobid.\n", (unsigned int)fsp->rap_print_jobid )); errno = EBADF; -- cgit