Three years ago, when I was asked to implement a DocumentCache class in the cinlib, I made a mistake so that first build that had it was actually horribly slower than before it was implemented. Yes, I admit it. But I fixed that problem in the very next build, and it actually did end up being a net gain.
So is it really fucking necessary that every time since then when there the slightest question about cinlib performance, the first words out of your mouth are “can we try disabliing the DocumentCache to see if that fixes it”? I mean, it’s been three years. Give it up, already.
I know the feeling. I wrote some baseline code 7 years ago that relies on the primary key, provided by a plug-in, to match up data.
Ever since, every time it breaks, someone comes running to me because baselining is broken. Every time, it’s been a plug-in changing the format or definition or something about their primary key. Despite many, many emails to product teams telling them that they cannot, ever, change their primary key without breaking baselining.
I’m in the process of designing the next generation of baselining, and I swear I’m going to figure a way to detect that the primary key has changed, and pop up a message telling them to contact the plug-in team.
Building one of my company’s codebases requires that people configure environment variables a certain way. Whenever the variables are *not* configured that way, they get a compilation error in a module that I wrote, because it happens to be the first one built.
So, at least once a week, somebody who didn’t RTFM asks why my code doesn’t build. And I don’t even work there anymore.
Cargo culting… it’s FAN-tastic.
By all means, fuck with the DocumentCache, Paul.
(Someone had to say it, and now that someone’s said it, we can all get on with our lack of lives.)