Random Acts of Optimization
engineering.riotgames.com
Random Acts of Optimization
1–10 of 128 posts
Re: Random Acts of Optimization
#2Clever! Never heard of doing that but it makes sense.
Re: Random Acts of Optimization
#3[1] (https://www.reddit.com/r/leagueoflegends/comments/2hvukl/smi...)
Re: Random Acts of Optimization
#4This is an interesting article, but Riot hasn't really earned any trust of mine at all as it comes to code quality; for a while they couldn't show the damage output of a spell because it caused the user's other summoner spell to go on cooldown for 15 minutes[1] when they tried. [1] ( https://www.reddit.com/r/leagueoflegends/comments/2hvukl/smi... )
Every code base has tech debt. You can't predict the requirements of the future, and even if you could, trying to account for them means you never release your product.
Re: Random Acts of Optimization
#5Re: Random Acts of Optimization
#6This is an interesting article, but Riot hasn't really earned any trust of mine at all as it comes to code quality; for a while they couldn't show the damage output of a spell because it caused the user's other summoner spell to go on cooldown for 15 minutes[1] when they tried. [1] ( https://www.reddit.com/r/leagueoflegends/comments/2hvukl/smi... )
"Its defects do not reflect issues with our code base (though there are many), but rather my own hacky implementation." Every code base has tech debt. You can't predict the requirements of the future, and even if you could, trying to account for them means you never release your product.
e: Addressing your edit:
Every code base has tech debt. You can't predict the
requirements of the future, and even if you could, trying
to account for them means you never release your product.
League is a mature game at this point, they have had a lot of time to fix longstanding issues. This isn't 'release day' woes.Re: Random Acts of Optimization
#7All of these steps can be efficiently automated. And it turns out that compiler writers collectively know about the vast majority of these techniques, but refuse to implement most of them for what I would consider to be the ultimate copout ever: Compile times. I don't know about you, but I would take 100x increase in compilation times for a release build over a 2x increase in development time due to manual optimization. I'm not sure who wouldn't, especially if it also allows you to eliminate technical debt, eliminate leaky abstractions, and improve code comprehensibility.
Perhaps I'm being overly idealistic, but I can't help but hope for a day that I can work with a high level language and have the compiler take care of optimizations that range from removing redundant elements from struct definitions all the way down to bitshift optimizations like i * 28 == i<<4 + i<<3 + i<<2. And if I have to wait all day long for a release build of something, so be it.
Re: Random Acts of Optimization
#8Last year's event generated more global viewers than the NBA final.
Re: Random Acts of Optimization
#9This brings up a thought that I've had for a very long time. Almost every type of optimization that a programmer could employ is repeatable. It involves matching patterns ("Identification" in the context of this article), analysis ("Comprehension"), and rewriting ("Iteration"). All of these steps can be efficiently automated. And it turns out that compiler writers collectively know about the vast majority of these te…
Re: Random Acts of Optimization
#10This brings up a thought that I've had for a very long time. Almost every type of optimization that a programmer could employ is repeatable. It involves matching patterns ("Identification" in the context of this article), analysis ("Comprehension"), and rewriting ("Iteration"). All of these steps can be efficiently automated. And it turns out that compiler writers collectively know about the vast majority of these te…