Hey, Root? How do you test your slow query ticket, again? I didn't bother reading the giant green "Testing notes:" box on the ticket. Yeah, could you explain it while I don't bother to listen and talk over you? Thanks.

And later:
Hey Root. I'm the DBA. Could you explain exactly what you're doing in this ticket, because i can't understand it. What are these new columns? Where is the new query? What are you doing? And why? Oh, the ticket? Yeah, I didn't bother to read it. There was too much text filled with things like implementation details, query optimization findings, overall benchmarking results, the purpose of the new columns, and i just couldn't care enough to read any of that. Yeah, I also don't know how to find the query it's running now. Yep, have complete access to the console and DB and query log. Still can't figure it out.

And later:

Hey Root. We pulled your urgent fix ticket from the release. You know, the one that SysOps and Data and even execs have been demanding? The one you finished three months ago? Yep, the problem is still taking down production every week or so, but we just can't verify that your fix is good enough. Even though the changes are pretty minimal, you've said it's 8x faster, and provided benchmark findings, we just ... don't know how to get the query it's running out of the code. or how check the query logs to find it. So. we just don't know if it's good enough.

Also, we goofed up when deploying and the testing database is gone, so now we can't test it since there are no records. Nevermind that you provided snippets to remedy exactly scenario in the ticket description you wrote three months ago.

And later:

Hey Root: Why did you take so long on this ticket? It has sat for so long now that someone else filed a ticket for it, with investigation findings. You know it's bringing down production, and it's kind of urgent. Maybe you should have prioritized it more, or written up better notes. You really need to communicate better. This is why we can't trust you to get things out.

*twitchy smile*

Spent 2 days carefully crafting a highly optimised routine, then spent 3 minutes to write an unoptimised version for benchmarking. The latter ran 50% faster.

I just discovered that my dedicated server is a tamagotchi laying around at somebody's home. While benchmarking cpu I discovered that it performed worse than my 4yr old chromebook with mediatek processor.

My new motherboard (MSI Z170 GAMING AC) reports temps for the memory, CPU, GPU and hard drive in °C. And the motherboard temp in °F.
Almost had a fucking heart attack the first time I opened Speccy for benchmarking.

I just realized that I subconsciously believe more lines of code means slower code.

It's not intellectual. I understand that little lines of code often are just calling other code. That this is not how Big O works or does not replace benchmarking and that some data structure requires a lot of code for immense speed up. E.g: B-Trees with sizes at page size for big amounts of data read from a secondary storage location.

But still, when I see a function with just 3 to 5 lines, my inner monkey believes it must be fast.

Know your biases, I guess.

Working on a poker card simulator. Currently benchmarking the hands by giving them a rating (high card value, pair).

In the simulation there are three players. The first player who get the hand cards first seems to have advantage. Does this make sense?

Hello guys!

Some context: our subject thesis is: "Benchmarking of IoT OS". We decided to narrow down the subject to a benchmarking of real-time OS. Examples of RTOS: Contiki, RIOT, ...

As there are no such papers on the subject out there, we are looking for some people/communities that could help us answer our questions.

Thank you for your time!

I created an application A which was faster than B. As the authors of B created a repo for benchmarking and mentioned

'Do you know other Bs? PR! :D'

I created a PR in Apr.

it is not accepted yet.

Today I found a small toy project in JS I was working on 2 years ago for few weeks. CQRS, fully tested, with IA simulating human behaviour and a benchmarking system... I wonder how much free time I had back then

There's been talk that UE5's Nanite isn't actually all that efficient (sometimes slower than the alternative) and that kind of got me thinking.

You give developers very high end machines so that they can move quickly. But that doesn't always translate to lower machines. When benchmarking how would you even target lower machines in a simple way? Like for me, I have two GPUs in my system, but one is passed through to a Windows VM. I'd love to test on that GPU but it's just not feasible

All the great test results I (and others) have been seeing might just be a result of the newest cards being insanely fast in relation to cache. Is visibility rendering really faster on a few generation old card? I don't know! Nvidia MASSIVELY beefed up L2 cache on the 4000 series. Does that play a role? Maybe even a big one...

Sometimes you spend x amount of time preparing an offer for a larger project to a respectable client. Then you might have lunch with your friend who works for the competition and do some shop talk while you are at it. You discuss in general ongoing interesting projects without disclosing details.

Suddenly you realize that you both are working on the same project by the same client and the competition is already hired for the job. Then you realize that you are used for benchmarking. =D