Quote Originally Posted by Hodor View Post
It almost seems as if you think that the compiler optimises at the C level. It's quite reasonable to assume that optimising compilers do a better job when you do break up large functions (using "helper functions") because optimisation doesn't generally happen at the C level but on an intermediate (abstracted) representation of whatever you write (see Intermediate representation - Wikipedia). Besides that, large functions are difficult to maintain and hard to understand for humans. Most optimisations that have any relevance depend on choosing the correct algorithm in the first place (and in some cases using keywords like restrict so that the compiler can optimise more aggressively, for example. restrict - Wikipedia Don't bother with register in general... the compiler will use a register if it makes sense anyhow). Doing stuff like you're suggesting is not just premature optimisation, it might be doing the exact opposite of what you're trying to achieve.

I guess an example (maybe not a good one) similar to what you think you're doing is a project I was working on last year. A co-worker submitted a cunningly constructed micro-optimised function with a scary comment saying I should not rearrange things because it was carefully optimised to minimise x86 cache misses and that it'd fit in the pipeline or some mumbo jumbo. The problem is that we were prototyping on x86 and the actual target was ARM. So, of course the carefully constructed function was BS, the ARM code generated was not optimal and the compiler already did a better job. If it's not clear by now: I hate micro-optimisations or giving hints to the compiler (apart from well-defined hints like restrict and inline) because in 99.9% of cases I've come across the compiler does a better job. Write clear code, use the correct algorithm, break down large functions and in general the compiler will do a very good job.
That co-worker sounds like he had the wrong idea, anyways the only in code optimizations I make are simple ones that can be understood at a glance by any coder with decent knowledge of C, would not go so far as to optimize to the specific CPU, merely enough optimization that the compiler is guaranteed to understand that no extra load operations are needed, I avoid doing a multi-level expression beyond that unless I'm trying to avoid one-time variables. Anyways enough of that topic for now, any ideas as to why this loop continues inifinitly?
Code:
for ( i = glance->process; i < glance->idNodes.count; ++i )
	{
		entryId = notice->ownerId =
			((int*)(glance->idNodes.space.block))[i];
		fputs( "Enter\n", stderr );
		while ( proc_notice_info( err, notice->ownerId, notice ) )
		{
			if ( notice->ownerId == glance->underId ) {
				glance->process = ++i;
				return proc_notice_info( err, entryId, notice );
			}
			if ( notice->ownerId <= 0 )
				break;
		}
		fputs( "Leave\n", stderr );
	}
I get a list of "Enter" outputs but never a "Leave" output, I've done a session check for calls to the function containing this and there are only 2, one for when a glance object is open and one for the proc_locate_name() function which calls it like this:
Code:
for ( notice = proc_glance_open( err, &glance, underId )
		; notice; notice = proc_notice_next( err, &glance )
	)
proc_glance_open() is never called elsewhere at the moment and proc_locate_name() is only called once by main()
I can't find any reason for the loop to restart itself without ever reaching the "Leave" statement