Page 2 of 4

Posted: Fri Mar 26, 2004 10:09 am
by Roja
McGruff wrote:
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.
Sorry, I have to contradict you: that is not how it's done.
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: Write, test, THEN optimise. I bet nine times out of ten you won't even need to do the latter.
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: 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.
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: 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
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 html
and php - resulting in mixed echos - sometimes as many as 90 (or more!) on a page - with poorly escaped variables, and more.
McGruff wrote: , we'd need an instrument more accurate than the Hubble telescope to detect the difference.
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%.

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.
McGruff wrote: The main aim of good design is flexible, modular code.
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!

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!).
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.
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.

OOP MAY = fast, but doesn't always.
McGruff wrote: Let's say we have two almost identical apps: one written by Mr Spaghetti and one carefully refactored
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: 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.
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).

Yes or no - echo can be (measurably, without using hubble) faster than print? Yes. End of argument on that point.
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.
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.

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.
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.
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.

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.

Posted: Fri Mar 26, 2004 10:18 am
by aleigh
McGruff wrote:
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.
Sorry, I have to contradict you: that is not how it's done. Write, test, THEN optimise. I bet nine times out of ten you won't even need to do the latter. 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.
Or, it's not how you do it.

Some things are fundamentally slow. Here's an example, let's take a threaded webserver. Going into a threaded webserver project it is a lot easier to program it to throw away threads and to also use TLS memory at the OS layer to store variables and state. You could say this is the path of least resistance and most productivity. This is really great; it significantly cuts down on the code you have to write, helping to yield that easy to maintain code you like so much.

Functionallity the server will work fine; it'll meet the application requirements and it will serve pages. But with your methodology we might write it this way and then later start to look at performance and realize that there was something to be gained.

At this point the die has been cast and going back and changing all the code to not depend on the framework of TLS memory can be anything from a challenge to a nightmare. You can patch the situation by trying to erase all the memory at the end of the thread, but then you realize you will have to kluge in more code to keep track of all the things that are used so it knows what to free, and that just makes things MORE complicated.

Why? Because we didn't sit down and try to anticipate the performance characteristics of the application back when we had whiteboards instead of code.

Performance like functionality is part of the requirements for the project and that's what the design should encompass; after all aren't we designing to meet the the needs? I sure hope so. If performance is not a big worry then hey everything is fine; but this is a decision also that you make ahead of time, before code is written. But if you know going in that performance is an issue and that it has to be fast it is definitly NOT something to leave until after the fact.

I think it's right to ask "what can I easily do better to design my programs to be faster"; and there are lots of things. For example we know that "foo" is slower than 'foo' and print is slower than echo. So why not just echo 'foo' early when you have the chance rather than realize you have a problem later and try to fix it? Again this is an overly specific example of a general theme; and my point is just that there are plenty of things that are just as easy to do one way as another when you are coding, but can impact performance.

Posted: Fri Mar 26, 2004 10:27 am
by penguinboy
Roja wrote: There are simple steps you can take - use echo instead of print. Its faster.
I've never seen any data to back that statement up.
Do you have a url to some testing?

Posted: Fri Mar 26, 2004 10:41 am
by aleigh
penguinboy wrote:
Roja wrote: There are simple steps you can take - use echo instead of print. Its faster.
I've never seen any data to back that statement up.
Do you have a url to some testing?
http://www.faqts.com/knowledge_base/vie ... d/1/fid/40

Posted: Fri Mar 26, 2004 11:07 am
by penguinboy
There is a difference between the two, but speed-wise it
should be irrelevant which one you use.
So, there's no noticeable performance difference.

Posted: Fri Mar 26, 2004 11:28 am
by aleigh
penguinboy wrote:
There is a difference between the two, but speed-wise it
should be irrelevant which one you use.
So, there's no noticeable performance difference.
Yep so it seems. I still think you are safe with '' v. "" though.

Posted: Fri Mar 26, 2004 11:43 am
by McGruff
McGruff wrote: I think someone mentioned using print in preference to echo ... we'd need an instrument more accurate than the Hubble telescope to detect the difference.
Roja wrote: 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 html and php - resulting in mixed echos - sometimes as many as 90 (or more!) on a page - with poorly escaped variables, and more.
What are we talking about here? I thought you were recommending replacing print with echo because of a significant speed gain. There is no measurable difference.

Incidentally, an 8% improvement in script speed should be regarded as wasted effort. Remembering internet latency, 8% of the (average) couple of tenths of a second script execution time is off the radar. If programmers are getting paid to do that it's been a waste of resources.
[/quote]
Roja wrote: 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.
I realise the orignal poster asked about speed. Db servers can be slow. Several large JOIN queries in one script can be slow. Failing to index appropriate columns can be slow. It's unlikely (but not impossible) that the script is a problem, at least in my experience.

I believe that a lot of new programmers get hung up on alleged "efficiency" savings. Hence I think it is important to steer people away from thinking about optimisation towards thinking about good design.

The scenario I outlined wasn't aimed at anybody - I'm sorry if you took offence. It's just an attempt to explain an important point: without a well-designed app, it's going to be tough to do any optimising at all.
Roja wrote: 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.
Refactoring separates the different threads in a script. A fundamental refactoring is to separate model & view for example.

Flexibility arises from paring down classes and fns until they do just one thing. Reduced dependency = more flexibility. An example: Iterator classes emerge from this kind of exercise as the refactoring reveals a common pattern. They have a stated and measurable purpose at the same time as increasing flexibility - the two aren't mutually exclusive.
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.
Roja wrote: 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.
That's really at the heart of the matter. Code isn't just a set of instructions for a machine. It's an interface between computer & programmer. The computer has to understand it and work with it, and the programmer has to understand it and work with it. Obsessive optimising focusses on the PC - where php offers scant rewards for your trouble - and ignores the real challenge of writing good code.
Roja wrote: 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.
Some things are a matter of preference, but I think this is a bad approach [ie trying to design from ground up]. Experienced programmers don't tend to work like that.

Posted: Fri Mar 26, 2004 12:08 pm
by McGruff
To aleigh: I think maybe we can agree that applications tend to "emerge" rather than sitting down to a design and then writing it all up. Has there ever been a program that didn't go through several re-writes and specification changes before the final version?

Sure you should try and make some intelligent decisions at the start, keeping as many options open as possible. Hence the importance of modular design (OOP) which many new programmers steer away from because they feel it is inefficient.

Php scripts don't usually offer much scope for significant gains - unless you're doing something really daft. As always there will be exceptions.

For the record, there is no measurable difference between "foo" and 'foo'.

Posted: Fri Mar 26, 2004 12:28 pm
by Buddha443556
McGruff wrote:Sorry, I have to contradict you: that is not how it's done. Write, test, THEN optimise. I bet nine times out of ten you won't even need to do the latter. 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.
Ok, we do seem to look at optimization very differently you consider it only part of the coding process. I see as an intergal part of the entire design and development process.
McGruff 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, we'd need an instrument more accurate than the Hubble telescope to detect the difference.
I agree the difference between print/echo is insignificant. However, I don't see optimization as some insignificant part of the design and development process either.
McGruff wrote:It's interesting you mentioned bad design since this, I think, is often a product of optimisation obsession.
Since you seem to think optimization is only a small part of the coding process, I can understand why you would feel this way.
McGruff wrote:The main aim of good design is flexible, modular code. 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.
I have to admit I do find openning a lot of files inefficient in PHP because it is a script language and not compiled before execution.
McGruff wrote:Let's say we have two almost identical apps: one written by Mr Spaghetti and one carefully refactored 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.

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. Mr Spaghetti spends all day just trying to figure out his own script - he's long forgotten how it works and the mess on the page doesn't explain itself. He spends all week looking for bottlenecks: because his script is so tangled, it's a huge effort to compare alternative ideas.
First I really don't think name calling, should be part of this discussion. Especailly when the one doing the name calling is a moderator. Stooping to such level doesn't help your arguement. Any one who has done any programming knows what Spaghetti code is. Furthermore, anyone who has any experience programming knows poorly organized and unstandardized code whether it uses classes or not is still Spaghetti.
McGruff wrote:Php isn't a language exactly, more of a vocabulary. To speak eloquently in php, you need to abandon "premature optimisation" and learn the language of design.
Very poetic.
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.
I always thought programming was 99% thought and 1% effort. Maybe I'm doing it wrong? :twisted:

Posted: Fri Mar 26, 2004 12:37 pm
by aleigh
Buddha443556 has it figured out.

Posted: Fri Mar 26, 2004 12:42 pm
by Roja
McGruff wrote: What are we talking about here? I thought you were recommending replacing print with echo because of a significant speed gain. There is no measurable difference.
1. There is - 8%. Thats not insignifigant, nor is it not measurable. Again, thats specific to one particularly poorly written page, but the point is - it can, and is, a possible signifigant, measurable improvement.

2. I wasn't being specific actually - I was giving general recommendations. The original poster would really need to show the code (or at least give some more specific generalizations about what its doing) to give specific recommendations on how to improve it. I mentioned echo v. print. I also mentioned poor loops, sql queries, and less-optimal choices of functions.

3. The point isnt in amount - the point is a specific, (yet generally applicable), possible overall improvement. What I was getting at was the possibility that minor changes can be made, that overall, will have an impact. Without the script, we can't make any value judgements about which is better.
McGruff wrote: Incidentally, an 8% improvement in script speed should be regarded as wasted effort.
Completely disagree. 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. Thats not a waste of effort. Your solutions (upgrade the hardware, do a OOP redesign) either avoid the problem, or use a sledgehammer to (only possibly) kill a fly.
McGruff wrote: Remembering internet latency, 8% of the (average) couple of tenths of a second script execution time is off the radar.
Average execution time of the script in question was over 10 seconds - not at all off the radar. Not to mention, you are again arguing impact - which means you agree that it has a net effect, just you feel its not a worthy amount, or worthwhile. Those points are opinion, and we disagree. Original poster asked for methods for improvement - I'm giving them, and you are arguing that they arent important. I say the same for your solutions. End of thread.
McGruff wrote: If programmers are getting paid to do that it's been a waste of resources.
Again, if the problem is speed, and it solves the problem - its not a waste of resources.
McGruff wrote: I realise the orignal poster asked about speed. Db servers can be slow. Several large JOIN queries in one script can be slow. Failing to index appropriate columns can be slow. It's unlikely (but not impossible) that the script is a problem, at least in my experience.
And in my original post, I agreed with that statement - I explicitly listed sql calls as a primary culprit. However, based on the incredibly limited information, I had to offer advice on how to get concrete improvements in a php script - I've given it.
McGruff wrote: I believe that a lot of new programmers get hung up on alleged "efficiency" savings.
I feel the same way about the current trend towards OOP. It has its place, it has a value, but I think many people - including you - confuse its real values with its POSSIBLE values.
McGruff wrote: Hence I think it is important to steer people away from thinking about optimisation towards thinking about good design.
And I feel its important for people to focus on the real issue as presented, and solve THAT problem, not some pie-in-the-sky ideal.
McGruff wrote: It's just an attempt to explain an important point: without a well-designed app, it's going to be tough to do any optimising at all.
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.

You may notice that that does lead me to agree with you on an important point - redesigning an app can have larger improvements than functional improvements here and there. I said that much in my original post, and we don't disagree on the core value of OOP. I simply feel that there is a time and place where OOP is most valuable - at the design (not polish) phase. If you are looking for improvement, improve (dont redesign) the code.
McGruff wrote: Flexibility arises from paring down classes and fns until they do just one thing. Reduced dependency = more flexibility.
I disagree. Flexibility means "Responsive to change; adaptable" - the opposite of doing just one thing, the ability to do many things as needed.
McGruff wrote:An example: Iterator classes emerge from this kind of exercise as the refactoring reveals a common pattern. They have a stated and measurable purpose at the same time as increasing flexibility - the two aren't mutually exclusive.
Nitpick - as I said in the last posting, they CAN both be accomplished, but refactoring favors simplicity and single-use OVER flexibility.
McGruff wrote:Obsessive optimising focusses on the PC - where php offers scant rewards for your trouble - and ignores the real challenge of writing good code.
And you are ignoring the actual problem - the script isnt fast enough - for the scant rewards of 'good OOP design'. Like I said, define the problem as "I need to know how to recode my page to a better design", and OOP is absolutely the answer. Speed however, doesn't neccesarily mean OOP is the right answer.
McGruff wrote:
Roja wrote: 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.
Some things are a matter of preference, but I think this is a bad approach [ie trying to design from ground up]. Experienced programmers don't tend to work like that.
I disagree entirely - I'm experienced, and I work that way, and up until XP and refactoring, it WAS the way it was done. XP tends to advise for evolutionary design instead of planned design, but XP isnt exactly 'old-school'. Different styles..

Planned design has been around longer, and thus I'd argue that the REALLY experienced hands do planned design, not this new-fangled XP stuff.. But then I might show my age. :P

Posted: Fri Mar 26, 2004 12:45 pm
by McGruff
Buddha443556 wrote: I agree the difference between print/echo is insignificant. However, don't see optimization as some insignificant part of the design and development process either.
We're talking specifically about php and web apps. Scripts will commonly take a couple of tenths of a second to execute. That itself is insignificant to the end user quite apart from the 8% speed gain (8% of that 0.2s) obtained from a script optimisation mentioned above. If your server is on its knees get new hardware.

There is not much to be had from optimising php. Given that, and the mutability of scripts during the development process, it's not worth spending time on. Test when it's done and find out if you actually have a problem before trying to fix it.

PS: I don't think my little story was insulting to anyone - it certainly wasn't meant to be.

Posted: Fri Mar 26, 2004 1:08 pm
by aleigh
McGruff wrote:
Buddha443556 wrote: I agree the difference between print/echo is insignificant. However, don't see optimization as some insignificant part of the design and development process either.
We're talking specifically about php and web apps. Scripts will commonly take a couple of tenths of a second to execute. That itself is insignificant to the end user quite apart from the 8% speed gain (8% of that 0.2s) obtained from a script optimisation mentioned above. If your server is on its knees get new hardware.
If I have a PHP script that takes 5 million hits a day, 8% of 5,000,000 is 400,000; so I am saving 400K executions worth of instructions; or the equivlant of running the script 4.6 fewer times per second. That is 8% more headroom on a production platform for $0 rather than the sum unit cost of another node, which could be anywhere from many hundreds to thousands.

8% for sudden peaks in usage, 8% for other software that would be
harder to optimize to run faster. 8% for that extra monitoring application to increase reliability.

Notice that I say $0; it is $0 because if you do it "our" way and design performance into the application in the beginning it doesn't really take any extra time. But it always takes extra time to go back and fix what's slow.

"No sorry, boss, I didn't save the company $1000 for that extra machine because it would have required a little more forthought and wasn't really worth my time that you pay me for anyways". Or I guess you could be telling the client "Here is your app, it could be faster but it would be cheaper for you to buy a new machine than pay me for the effort to make it faster".

Don't forget the cost of deploying that hardware, too. If you try to say that the hardware is cheaper than the programmer cost you also have to look at the admin cost on the deployment of hardware; hardware that more often than these days is colocated where people pay per-u; added costs.

It's good to hear that at least some companies must be willing to throw hardware at bad software; we were like that back in the 90s too but now doing more with less is pretty appealing.

Performance is part of design; not an afterthought!

Posted: Fri Mar 26, 2004 1:20 pm
by McGruff
McGruff wrote: It's just an attempt to explain an important point: without a well-designed app, it's going to be tough to do any optimising at all.
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.. :)
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. Even if you can't physically get your hands on the box, you can upgrade your host plan or get a better host. You have to keep a perspective: hardware is cheap, programmer's time is not.
McGruff wrote: Flexibility arises from paring down classes and fns until they do just one thing. Reduced dependency = more flexibility.
Roja wrote: I disagree. Flexibility means "Responsive to change; adaptable" - the opposite of doing just one thing, the ability to do many things as needed.
McGruff wrote: An example: Iterator classes emerge from this kind of exercise as the refactoring reveals a common pattern. They have a stated and measurable purpose at the same time as increasing flexibility - the two aren't mutually exclusive.
Roja wrote: Nitpick - as I said in the last posting, they CAN both be accomplished, but refactoring favors simplicity and single-use OVER flexibility.
Sorry I have to say this is a mistake. Refactoring SPECIFICALLY creates flexibility. Let's say I print some data from a db in a table. I also need to print another table but this time the data is in a file. Somewhere in the class hierarchy is a class which prints tables. It doesn't care what kind of table. I can (using an Iterator) feed it data from a table or from a file - or anything else you care to think of. Ruthless refactoring makes that possible. The more focussed the components become the easier it is to re-use them or recombine them in different ways. That's where the flexibility comes from.

I think we are starting to go round in circles a bit. I guess we'll have to leave others to judge for themselves.

Posted: Fri Mar 26, 2004 1:26 pm
by penguinboy
aleigh wrote: "No sorry, boss, I didn't save the company $1000 for that extra machine because it would have required a little more forthought and wasn't really worth my time that you pay me for anyways". Or I guess you could be telling the client "Here is your app, it could be faster but it would be cheaper for you to buy a new machine than pay me for the effort to make it faster".
All the Bosses I've worked for have had one thing in common;

a motto:

'Get it done quick.
Get it done now.
Optimize later.'

And they only(read: never) support optimizing when performance becomes a problem.