51–60 of 86 posts
That's exactly how i managed to enhance the performance of my site. https://vashishthakapoor.com/ Keeping the features along with performance is a big challenge. Video is really explainatory to fix performance issues.
Earlier quoted context omitted.
> We have computers which are ridiculous fast, but tend to write code which is freaking slow. It's sad that most programs could be 100x faster. I feel this sort of comment misses the whole point of going with code which is patently slower than alternatives. The main reason is that performance is a constraint but not a goal, and once it is good enough then there is absolutely nothing to be gained by wasting time on se…
> Performance is meaningless once it's good enough. There is no level of performance that is "good enough". One person's "good enough" is another person's "pain to use" and it's someone else's "I can't buy that computer that I would like because it will not run this software well". Faster software means more options for the consumer, less energy usage and it will be easier to make computers because they don't have to…
So there is, in fact, a performance level that's good enough: faster than doing it manually, or as fast/slower but more correct. That's the point at which software becomes useful.
Earlier quoted context omitted.
> Performance is meaningless once it's good enough. There is no level of performance that is "good enough". One person's "good enough" is another person's "pain to use" and it's someone else's "I can't buy that computer that I would like because it will not run this software well". Faster software means more options for the consumer, less energy usage and it will be easier to make computers because they don't have to…
That's only considering part of the equation. We use software because it does things faster or more correctly than us. A slow and bloated spreadsheet software will still be usually way faster than manual calulation, and more correct. That way, you can understand why some people would prefer more features to faster software. The new feature allows people to do some things way faster than before. Because when a softwar…
I would not call a 30 minutes website load time good enough, even if it takes 31 minutes to travel to visit the company's office physically.
That's because I know that it could be much faster. Traveling for 31 minutes is acceptable because maybe it could not be done much faster.
Earlier quoted context omitted.
“Good enough” is defined by the inability of stakeholders to conceive of transitive benefits. Compute performance suffers the tragedy of the commons.
> Good enough” is defined by the inability of stakeholders to conceive of transitive benefits. The whole point is that there are absolutely no benefits, at least relevant ones, once the performance is acceptable. It's a diminishing returns game. There is always a tradeoff between performance and cost, and once performance is acceptable then it's hard to justify wasting more resources to get nothing of value in return…
Earlier quoted context omitted.
This has been the prevailing mentality in the industry for a long time, being essentially a business dogma in IT since the 90s (for a good reasons, as you explained). I think Java is the personification of this concept (more specifically idiomatic corporate Java from the 00s). But there is a recent small change of winds, where management is realising that being faster than the competition can have some business merit…
> That is one of the drivers of the recent growth in compiled languages (Rust, Go, ...), Not the only one but it helped. No, not really. In either case (rust, Go) perfomance is at best a nice-to-have, while their main value proposition is, and has always been, turnaround time and consequently man*hours. Rust is marketed primarily due to their first-class support for safe programming constructs, and providing a far be…
(1) Software already has acceptable performance.
(2) Further work to improve its performance is likely to have large development costs but deliver only small benefits.
I’m not sure either of those assumptions is safe. As the early parts of the lecture we’re discussing today demonstrated, sometimes there are dramatic performance improvements that can be made if you know what you’re doing and they can make a similarly dramatic difference to how beneficial the software is to its users.
Earlier quoted context omitted.
“Good enough” is defined by the inability of stakeholders to conceive of transitive benefits. Compute performance suffers the tragedy of the commons.
> Good enough” is defined by the inability of stakeholders to conceive of transitive benefits. The whole point is that there are absolutely no benefits, at least relevant ones, once the performance is acceptable. It's a diminishing returns game. There is always a tradeoff between performance and cost, and once performance is acceptable then it's hard to justify wasting more resources to get nothing of value in return…
Define acceptable. (Hint: you can't)
Earlier quoted context omitted.
That's only considering part of the equation. We use software because it does things faster or more correctly than us. A slow and bloated spreadsheet software will still be usually way faster than manual calulation, and more correct. That way, you can understand why some people would prefer more features to faster software. The new feature allows people to do some things way faster than before. Because when a softwar…
> So there is, in fact, a performance level that's good enough: faster than doing it manually, or as fast/slower but more correct. I would not call a 30 minutes website load time good enough, even if it takes 31 minutes to travel to visit the company's office physically. That's because I know that it could be much faster. Traveling for 31 minutes is acceptable because maybe it could not be done much faster.
I love these videos, it's the kind of no BS programming to press performance on modern computers. Also recommend the Handmade Hero series of him. We have computers which are ridiculous fast, but tend to write code which is freaking slow. It's sad that most programs could be 100x faster.
> We have computers which are ridiculous fast, but tend to write code which is freaking slow. It's sad that most programs could be 100x faster. I feel this sort of comment misses the whole point of going with code which is patently slower than alternatives. The main reason is that performance is a constraint but not a goal, and once it is good enough then there is absolutely nothing to be gained by wasting time on se…
On the other hand, premium games generally generate little to none revenue after release. The gameplay and hardware would likely be different for the next title. For instance the rendering architecture changed from forward, deferred, to cluster in response to new hardware capabilities. Which means the maintainability and reusability of the game codebase is less important compared to other software projects. Also there is a tendency that game programmers receive less compensation compare to other industries (Higher supply of junior devs), so the calculation of man * hours would be different as well.
Earlier quoted context omitted.
In my experience, people waste performance and manhours at the same time. Many abstractions create more code instead of reducing it, at the same time making the code slower, harder to read and maintain. Would you rather maintain a couple hundred lines of straightforward code or thousands of lines of class hierarchies with delegates and whatnot? See John Carmack on Inlined Code : http://number-none.com/blow/blog/progr…
> Would you rather maintain a couple hundred lines of straightforward code or thousands of lines of class hierarchies with delegates and whatnot? I feel this is a gross misrepresentation of the problem. With higher-level frameworks, you can add complex features with one-liners, which by their very nature (generic, extendable, and general purpose) are bloated and underperform when compared with the code you could roll…
The highest level framework isn't always the one best suited to solving the problem you have. Maybe it's a one-liner, but due to the overhead you have to run a giant distributed system instead of a single machine with share memory. Then the overhead of orchestrating all these machines might be more than writing 10 lines in a lower level framework.
Earlier quoted context omitted.
Thanks for sharing the challenge and so cool to see the follow up and your actual answer. Here's a linear solution I came up with, before I took a look at the rest of the thread: 1. Think of the 100x100 as pixels on a black background, all set to 0, i.e. all open space. 2. Now, draw a white square border all the way round by setting all the outer pixels to 1. No one can get in. 3. Leave a pixel gap and draw another s…
You would risk ending up with a maze that can be solved by walking in a straight line directly to from start to exit.
I guess this could either be fixed up later with a simple check at the end, also linear, just in case it ever happens, or even just a condition whilst placing gates, that they can't be directly opposite the last gate placed but must be some x/y distance away.
Even without any check though, with a 100x100 grid, this is highly unlikely to happen often, as all 50 or so square borders would need to have their gate on the same side of the square, and at exactly the same position.
That's a few probabilities that would all need to intersect, i.e. I believe somewhere on the order of 1 in Math.pow(1/(100*4), 50) unless my probability theory is way off.