McGruff wrote:
Roja wrote:
I disagree with that statement completely - the LESS well designed the app, the MORE benefit you can get from optimizations. If its well designed, its going to be VERY challenging to improve that.
I don't think you really meant to say that..
On the contrary - I did.
Lets say a totally crap design is 10%. Then lets say you improve that 40% - now its 50%, which we will call "passably average".
To take an application from 50% (passably average) to 90% is completely and totally
much harder than getting from crap to passable. Its a logarithmic progression at best - maybe even higher. The higher up the 'perfection' slope you get, the harder it is. At 90%, good luck for even a 1% improvement.
Thats why the context of the original poster matters.. if he's at 10%, I can make a great argument that my improvements would be faster, easier, and much more beneficial in terms of return on programmer time investment. If he's at 90%, I can absolutely guarantee that there is almost NOTHING my techniques would do to improve things, while moving towards a refactor/redesign would be extremely beneficial.
Thats the point I've been making since my first post - both have value, we just disagree on where they
have value. You think OOP is better in more places, I think procedural fixes are better in more places. Simple diversity of opinion, and I do respect yours - although I have a different one.
McGruff wrote:
Roja wrote:
If you don't have control over the hardware, and your problem is that the script is not fast enough - it is a direct solution to the problem at hand.
But you always have control of the hardware.
Not at all true - Did you read my post??!? I specifically explained why you don't. If you write your app for OTHER people to deploy - for example a backend code (database abstraction, login system, template system, etc), or even a game (other people run it on their servers), then you DO NOT have control over the hardware.
At best, the people DEPLOYING the game or the backend MIGHT - but the vast majority of the people deploying the two projects I mentioned DONT. They are admins running the games/backends on webhosting accounts, which they don't control the hardware for. Thus, in that situation, as the coder, I do not have control of the hardware, and neither do the people deploying the code. Hence, speed MATTERS.
McGruff wrote:
Even if you can't physically get your hands on the box, you can upgrade your host plan or get a better host.
No, the admins deploying it can - and that means reducing the target audience. For example, if my game wont run on a 256mb hosting account, thats (off-the-wall guess) 20% less admins that can run my game. If it wont run on an account with MySQL (like if I switched to only supporting postgresql) suddenly, its 40% less admins that can run my game.
And your argument is that that is an improvement over spending time optimizing the code?
McGruff wrote:
You have to keep a perspective: hardware is cheap, programmer's time is not.
And I say you need to consider the problem - in my projects, the hardware is a fixed commodity, where you have no control. The market dictates the common platform for webhosting - the larger the requirements, the less people will install it. Suddenly, the programmers time is much LESS valuable than the market share is.
McGruff wrote:
I think we are starting to go round in circles a bit. I guess we'll have to leave others to judge for themselves.
I think in many ways, I agree totally.
We simply see things differently - you are more yin, I am more yang. No problems with that.
In the future, please focus on the issues at hand - the thread was about optimization. You have made valid points about how OOP can be used in that context, and I didnt disagree that it had a value. You however, did disagree that MY suggestions had any value.
My problem was that you took my ideas, implied that they were spaghetti coding, said that "its not the way its done", and then said "its not the way experienced programmers do it".
All of which does little to offer the original poster advice on how to improve his performance - but does reduce the value of what I offered the original poster. If a moderator will offer little in the way of constructive advice beyond "make it OOP", at least don't insult those of us offering concrete examples of how to improve things.