2018-08-10 09:26:29 (edited by GrannyCheeseWheel 2018-08-10 09:27:50)

When I was growing up in the early 90's, and even before that, programmers had to squeeze every little drop of performance from the system they were coding on, all while keeping the memory foot print as small as they could make it. Computers just did not have the sort of power they do now, and it took clever tricks to pull off certain features. Now, you don't see a lot of that, or at least, I don't. It seems like everything is made in such a way that you really ought to have a dual Xeon machine or it won't run.

This practice of coding intelligently is a thing of the past, or at least, I hope its not, because a lot of the time, it seems so. You used to allocate memory and use what you allocated, freeing it up when no longer needed. Tight code is elegant code in my opinion, but now with high level languages doing all the work for you, and the internet being this all-in-one compendium for anything and everything you want to do, people just don't bother. The stuff on the net doesn't teach these practices, and people learn from those articles, and not bashing them, but you used to often times have a mentor. I have a mentor, that person teaches me even though they must, god I hope must realize by now that I always will suck at programming, even though I do get better, I don't have a knack for it like some folks do. But my mentor never had to say to me this is what you do, you have to try to make your code as compact as possible, while maintaining the functionality. It's just common sense to me.

So after unsuccessfully attempting to create a poll, again I will just write the question out:
When do you think about performance and optimization?

  a. I don't know, I let the language worry about that.
  b. From the very first line of code onwards
  c. It's not my problem, if your shittop cant run my software, fuck you, get a better machine, pleb.
  d. I think about it, but I don't know how to write better code or I would.

Facts with Tom MacDonald, Adam Calhoun, and Dax
End racism
End division
Become united

2018-08-10 12:18:00

I don't usually develope games. But, optimization is more important if you are doing an activity that requires a lot of resources such as heavy computations. The reason why you may notice that it people aren't allways thinking about it is that most projects don't use enough computer resources such that officiency is an issue.
For instance, I note, that in this comunity, their isn't too many actuall 3 dimentional games with sound.
Sorry if I am misleading.

2018-08-10 13:06:38

@1: I agree. In my CS classes, I had teachers who learned during the time when optimization was essential, so they would sometimes bring up these things in class, then add a verbal footnote that it's not really important anymore. Given that Abe's Odyssey and Duke Nukum 3d both run on an Acer from 1998, but modern software that doesn't require the same amount of resources struggles with modern machines... mwhthinks we have a problem.

I'm sorta contradictory in how I approach code optimizations. I almost always have efficiency in mind, both in terms of memory and speed (and size of the final product). On the other hand, I've mostly worked with Java, pre-2010s javascript, BGT, and Python. I've used C some, some, messed around with Visual Basic and Q Basic and PHP, but mostly just stick to the JBP quartette. And that's terrible.
And that's how I discovered that Java's "make a new object for every tiny operation" model results in an outlandish infant mortality rate, and memory and speed both benefit from doing things ... not the Java way. And that this doesn't actually matter much for BGT because it and my computer are both asses. ... Does that make my games colts? hmm
So yeah, I pay attention to efficiency from the beginning, but not uncommonly miss things, and still can't find the spoons for the C++ stuff or the tedious sound engines out there.

看過來!
"If you want utopia but reality gives you Lovecraft, you don't give up, you carve your utopia out of the corpses of dead gods."
MaxAngor wrote:
    George... Don't do that.

2018-08-10 16:05:46

To me, its important and I always try to write the most condensed and operationally efficient code I can manage.

Facts with Tom MacDonald, Adam Calhoun, and Dax
End racism
End division
Become united

2018-08-10 16:22:26

The problem with code like this is that writing the most compact or most optimized code is not exactly easy. And the huge problem with the idea of "allocate what you want and free it when unneeded" has its own issues, mainly the fact that people will forget the freeing part and cause memory leaks. That's why most high-level languages do all the memory management these days -- people just forget to do it and huge issues arise because of it. And no, you don't really need duel-core Zeon processors to acomplish your goal. My processor works just fine -- and that's with a game with all its graphics settings on and at the highest settings. Oh, it lags, sure, but it still works. Resource efficiency really isn't an issue any more purely because (for example) most compilers, i.e. GCC, will wash away anything that's redundant and/or inefficient and replace it with efficient alternatives, so long as you give it the right parameters. But optimization isn't all about the compiler either. You've got to unload things that you no longer use. This can usually be done automatically via methodologies like RAII, but some people don't do that, so might forget about it. The problem about unloading things you don't need (in games in particular) is that if you unload all the sounds you don't need for a custom map after the map is done being played, you have to wait extra time for those sounds to be reloaded and the map to be recreated. So there are pros and cons to writing code like they used to do in the 90s and pros and cons to writing code with the resources we have now.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

2018-08-10 21:49:09

I'd personally only optimize code that will actually run a lot of times. Also keep in mind that making code the most efficient and making code more readable are two different things. So a gui should be written with code that focuses on readability, whilst code playing sounds, doing computations, drawing graphics very often should be optimized as much as possible. In python, it would be possible to achieve this using cython: you can give python hints what a given variable will contain to skip many checks.

Roel
golfing in the kitchen

2018-08-11 10:55:04

Optimization is still very much needed, because a compiler can only do so much. I once saw someone inserting values into an array by shifting every element forward and adding the new element to index 0. This is bad because of the way caching works. Things like this can be avoided if a few smarter approaches were employed. (Mind you, this kid was in the beginnings of his CS career, and I hope that five years later he's gone on to be a great Computer Scientist, so he was still new in the world of computers.)

In the case of IoT devices and things like Smart Contracts, optimization is very much needed by the developer, because those are situations where choosing between an

O(n^2)

and

O(log n)

algorithm will have very real consequences. Further, we are developing a system at my company right now where for one week straight, we were discussing nothing but run-time complexity because we needed to optimize an algorithm that, had it not been optimized, would have led to realized slow-downs in performance. Eventually we went from

O(m+n)

where m and n are input sizes to

O(log(mn))

, and we all celebrated at this accomplishment.

So, perhaps optimization isn't needed in regular stereotypical desktop applications, but it is certainly needed in other applications.

And, people who don't bother with optimization typically don't work in environments where it's needed. For instance, while we were discussing run-time complexity, I was surprised how many of my fellow software developers had never heard the term run-time complexity before, much less how to come up with an expression for it. That's when I realized: wow, people really don't pay attention to this stuff anymore. It breaks my heart when a "CS major" doesn't know run-time complexity because it feeds into that stereotype that Computer Science is programming, when in reality I only took two programming courses in my entire CS degree.

2018-08-11 13:25:55

That shifting everything by one and inserting an element at index 0 sounds like something I would do tongue Although I can see how it would be computationally expensive in large arrays.

Facts with Tom MacDonald, Adam Calhoun, and Dax
End racism
End division
Become united

2018-08-12 04:22:19

@8, shifting bits like that either left or right is actually computationally expensive. In Python, at least. For example, bit-shifting a number (1<<i (where is an int)) by 1-100 takes between 0.013643076167937807 seconds (for 1<<1) to 0.01879656297867882 seconds. That's a 0.005153486810741015 seconds difference. But if you bit-shift an array by 1<<100000, which, on my machine takes 0.57 seconds, times can exponentially increase. If we bit-shift it by 1<<1000 10000000 times to get a good average, we get 0.78 seconds. If we do 100000 times, though, our times exponentially increase -- 5.863712047910667 seconds! I try to optimize my code -- I really do -- but I'm certainly not the best. One good way to optimize code is to cache entries. But you need to be careful: cache to much and you risk an OOM condition. Cache too little and you cause load time.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github