I think it depends on your purpose. If you are trying to assess the overall performance of the code or environment, then I'd encourage you to run it however you think most people will run it on a desktop environment: leave things open but make sure nothing is crunching in the background or hogging all the memory. The biggest culprits, in my experience, are backup tools during archive cycles and browsers with lots of and/or runaway tabs. If you're afraid that the performance difference is getting lost in the noise, then it probably isn't significant from a desktop user point of view.
If you are trying to evaluate the performance of a specific, potentially small code or environment change, then there is a trade-off: you can be more careful with shutting everything else down to reduce noise or you can try to isolate or emphasize that change to boost the `signal' in your experiment. I tend to prefer the latter, but your mileage may vary. This is related to profiling, for example here and here.
Someone else can give a better answer for getting the most precise timings, but for desktop experiments, I think it is overkill.
Things to look out for:
- Hyper-threading can lead to confusing results. Though, if users won't bother turning it off, it could be relevant for overall time. (disable in BIOS)
- Turbo-boost poses similar issues to hyper-threading. (disable in BIOS)
- Threaded BLAS libraries can make 'single core' runs parallel (disable with OMP_NUM_THREADS=1 in environment)