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/printing/printing.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'source3/printing/printing.c') diff --git a/source3/printing/printing.c b/source3/printing/printing.c index 49bd5ac8ba..fc3667ea3a 100644 --- a/source3/printing/printing.c +++ b/source3/printing/printing.c @@ -117,7 +117,9 @@ bool rap_to_pjobid(uint16 rap_jobid, fstring sharename, uint32 *pjobid) if ( data.dptr && data.dsize == sizeof(struct rap_jobid_key) ) { struct rap_jobid_key *jinfo = (struct rap_jobid_key*)data.dptr; - fstrcpy( sharename, jinfo->sharename ); + if (sharename != NULL) { + fstrcpy( sharename, jinfo->sharename ); + } *pjobid = jinfo->jobid; DEBUG(10,("rap_to_pjobid: jobid %u maps to RAP jobid %u\n", (unsigned int)*pjobid, (unsigned int)rap_jobid)); -- cgit