Posted: Fri Mar 26, 2004 10:09 am
Contradict and repeat your position as you please. I'll do the same - it can be how it is done, and there are concrete benefits and reasons to do so. It also IS how it is done - different places, different people, different approaches and problems to solve.McGruff wrote:Sorry, I have to contradict you: that is not how it's done.Buddha443556 wrote:Optimization should starts before you write a single line of code. Consider your design and figure out where the bottlenecks are in your design. Figure out how to fix those problems then you can start coding.
Bad designs can't be fixed in maintenance cycle.
Just one heretic's opinion.
Read the original post - "The downloading time of my page is very slow" - He *does* need to do the latter. In fact, he is specifically asking how to optimize. I also gave specific reasons why paying attention to optimization during coding can - and is - measurably helpful.McGruff wrote: Write, test, THEN optimise. I bet nine times out of ten you won't even need to do the latter.
For seasoned veterans, it is! For new coders, its not at all. Top problems I see in new programmers code? Over-use of arrays. Bad loops. Poor SQL statements. All things that you (aware or not) learn not to do in time.McGruff wrote: Maybe I take for granted a lot of things I've learned and just do instinctively but it's actually quite hard to write slow code.
Depends on the page, the program, and the content being output. If you return to my post, you'll see that I was maintaining (and improving) a legacy app that was written LONG ago. Said app had NO seperation of htmlMcGruff wrote: I think someone mentioned using print in preference to echo. Given that there are commonly about a dozen vars to echo/print on a page
and php - resulting in mixed echos - sometimes as many as 90 (or more!) on a page - with poorly escaped variables, and more.
On the contrary, on the most problematic page, the difference was an over 8% (consistent, across multiple servers and platforms) improvement. Don't need hubble for 8%.McGruff wrote: , we'd need an instrument more accurate than the Hubble telescope to detect the difference.
For independent verification of other coding choice issues, see blueshoe's wonderful function v. function benchmark page. While loops at 5000% the speed of a comparable foreach loop - need a telescope?
Point is - depending on the code and the application, there can be sizable benefits from the very MINOR recode of simply switching functions.
I disagree. Good design aims for FUNCTIONAL code first. Then all the secondary goals come into play - security, maintainability, flexibility, modularity, and possibly even well documented code!McGruff wrote: The main aim of good design is flexible, modular code.
To clarify my point, you beleive good design focuses on flexible and modular code. I beleive good design focuses on functionality, and then - based on coder preference - focuses on secondary goals. You didn't even mention security, and I consider that a high-priority goal (even above flexibility!).
And - despite the current trend fawning on OOP - sometimes modular, OOP-designed code ISN'T more efficient. It may be more maintainable, more re-usable, and a better design. That isn't the goal here - speed is. The original poster asked for SPEED. Sometimes OOP helps with that - sometimes the abstraction reduces speed.McGruff wrote: Modularisation means OOP. OOP means lots of code that defines layers and structure in an app but doesn't "do" anything. New programmers often see this as inefficient, failing to understand its purpose. So, they write global spaghetti instead (everything mixed up together in the global scope) thinking that's good, efficient code - often without even doing any tests to compare alternatives.
OOP MAY = fast, but doesn't always.
Now wait a second! Above you go into great detail about flexibility - something that refactoring strives to REDUCE! Refactoring means moving towards code built specifically for a functional purpose that can be measuerd and stated - the opposite of flexibility. I'm not saying you can't have lean OOP functions - just saying that refactoring generally steers you away from flexibility, and you listed that as a goal above.McGruff wrote: Let's say we have two almost identical apps: one written by Mr Spaghetti and one carefully refactored
I have existing code, with real-world improvements. I'm far from Mr. Spaghetti, and thats your implication - its rather rude (especially from a mod telling people not to call others insane). (You specifically refer to my suggestion as only being measurable by Hubble, and then use it in this example - if a personal insult wasnt the intent, it definitely came across that way to me).McGruff wrote: into lean & mean classes by Mr Oop. Both work, and Mr Spaghetti constantly annoys Mr Oop (who has better things to do) with the latest sightings on the edge of reality from his Hubble telescope.
Yes or no - echo can be (measurably, without using hubble) faster than print? Yes. End of argument on that point.
Your argument becomes clear - MAINTAINABILITY is your benefit here - NOT speed! Do I agree that OOP can be more maintainable, and in the example you give, possibly faster as a result? Yes! I said that much in my post.McGruff wrote: One day the client wants to make a big change to the site. The update is carried out, both sites are still using the "same" underlying code, and both have slowed right down. Mr Oop starts examining the system to find the bottleneck. Within an afternoon, with his nice modular design, he has identified the problem and swapped out the problem code.
However, the original poster wanted to speed up an existing page - you offered OOP (a redesign of the existing code towards maintainability and modularity), and I offered specific function replacements that can improve existing code without a full redesign.
Funny, I'd say that 2/3rds of the effort of programming goes into writing code that makes the computer do the RIGHT stuff - the rest (security, maintaibility, and so on) is a challenging task - but one that gets easier with experience.McGruff wrote: At least 2/3 of the effort of programming goes into writing code that is easy to assimilate and easy to work with. The other side of that, making a computer "do stuff" is a relatively trivial task.
We have different programming approaches. Saying "Thats not how it is done" is both misleading and wrong. It is done that way, and this way, and other ways! There is no one right way - if there was, this would be Python.
The original poster wanted to speed up his page. I have now given specific examples, functions, and methods for speeding up his existing page.
You've suggested an OOP redesign without specifics.
Different approaches - both valid.