Doing the cache invalidation is best for speed.
I am personally the type of person who thinks that every problem needs two fixes, first is the fix for the problem, second is the fix as to why the problem came into existence and/or was not found earlier. Hence I like to know that when I invalidate cache that this was really the problem, not just the delay in the processing or change in execution speed. To do this I tried replacing cache invalidation with a delay. That is if the delay fixed the problem maybe it is not cache. Second I put the buffers in not cache memory and check that it fixes the problem. Once I know and understand the root cause I can fix the problem and know it has been truly fixed.
As far as optimizations I have found that as Donal Knuth said "Premature optimizations are the root of all evil." Hence I never optimize code until it is needed. I have actually found that many projects the debug build "-O0" is fast enough for the applications. I find more and more customers are shipping -O0 code in production. I even find that they have to do this because they forget the little things like making the variables that need it volatile. So by shipping -O0 their code works where with higher level optimizations their code fails. .
What I have found that is more important than speed optimizations these days is designing the code for change and reuse. That customers always change requirements and code operation so designing and coding such that you can make changes quick and easy is the most important "optimization" that I do.
I often tell people if you have to optimize code for size or speed, you most likely picked the wrong processor. That is unless you are shipping millions of units the cost difference in cost of processors will be insignificant compared to development time.
Trampas