News for hackers. Stuff that matters.
Re:Lead Bullets (2011) by Sharlin on Thursday May 30, 2013 @04:10AM (#5791435)
Instead, look at the architecture and think a little about what the heck the poor computer is being asked to do. Then look at where the computer resources are going. Likely then, tweak the architecture: So, if are spending time walking down arrays or linked lists in O(n), then consider using an AVL tree in O( ln(n) ). If executing the code for a page when know that the output will be the same as the last 10 times, then cache the output and don't run the code again. If caching the output in main memory, i.e., virtual memory with page faults, then consider just using disk file for each page to be cached and save on page faults. If are connecting to a database, then have a pool of connections. Etc.

I read the original article pretty differently. As far as I can see, these all are exactly the kind of lead bullets the article meant. No miracles, nothing that doesn't directly involve making your product better, just some good old-fashioned programming work. The author's point was that if you have an inferior product, you roll up your sleeves and make the product better.

Re:Lead Bullets (2011) by graycat on Thursday May 30, 2013 @10:00AM (#5792493)
Yes, the AVL trees are like you describe, but the caching may not be because it's not clear to me (and I'm writing for ASP.NET and IIS although have yet to look into caching) if knowing when could cache needs just a lead bullet or a silver one. For more, I'm not deep enough into the internals of ASP.NET, the Windows 'global assembly cache', just how SQL Server connection pools work, etc. to know where the silver bullets would be in such work. So, my examples of bullets are too close to lead bullets unless the price of silver has declined a lot!