I think you missed the point of the post (did you even read it?). I’m not trying to explain what software performance engineering is, and no I’m not “surprised to learn” what it involves. All this article is trying to point out is that focusing on performance early and placing a high priority on it right away can cause you to lose focus on building your actual application, which is where most of your focus should be in the early start-up stage.

Please don’t try to use this blog as an advertisement for your products.

Standard profilers yes but most next generation (especially ones designed for cloud computing) are contextual and multi-language and multi-resource solutions.

Metering the Cloud
http://www.jinspired.com/products/jxinsight/meteringthecloud.html

William

Performance engineering that involves the creation of models via simulated or actual benchmarks (system execution) or trace executions (software execution) can be of enormous benefit as one learns about the dynamic software execution and not just the code in front of the screen and how one thinks it is called and executed.

There are a number of performance engineering related activities that should be conducted on any real-world application though with varying degrees depending on the levels of risk and cost implications.

eXtensible Software Performance Engineering
http://www.jinspired.com/solutions/xpe/index.html

Any activity that increases ones knowledge of how a software executes (frequency, resource usage and not just timing) is of benefit to the organization beyond the narrow and time limited world of a developer.

William

But it should not be forgotten either, and that’s what an automatic profiling would do. It would only pinpoint the bottlenecks of your application. With that report you could choose what to do before it’s too late. Someone experienced (like the project leader) could use it to detect a bad database design that would be hard to change when your project is feature-complete, for example. It’s worth it for that kind of scenarios. Everything that you can optimize later should wait. But sometimes you can’t optimize later.

That said, since there’s no tool to automate profiling yet, my opinion is completely arguable. And since there’s nothing yet, all developers should follow your advice.

I do agree with you that micro-optimization isn’t ONLY bad early, but I’m not sure about automatic profiling. It seems like even that little bit of performance profiling waving in your face every time you run tests would get you off track in your development.

I guess the main point of the post is to indicate that focusing on performance – micro-benchmarking or anything else – too early on will de-rail your development. You start thinking about shaving milliseconds here and there instead of focusing on getting your project done and moving forward.

For some projects, performance is never a concern. But for the others, actual profiling doesn’t have to wait until your project is almost completed.

Profiling reports can be generated automatically, just like for unit testing. These reports can reveal architectural problems that can become very hard to improve later in the project (for bigger projects anyway). They can give you a summary of the biggest problems. With that kind of tool you could just build your application and know *directly* what is going to be a problem performance-wise.

The problem is that this kind of tool doesn’t exist yet. It could be easily integrated in unit testing tools; after all, you could very well process an xdebug profiling output automatically (xdebug_get_profiler_filename) and display the biggest issues in your application, if you couple it with unit tests and/or (better) selenium tests to ensure every parts of the application are tested. You could also retrieve information about the efficiency of the queries performed (both time and EXPLAIN output), and add a data generator to the mix to make sure those queries still perform well with millions of rows.

If the report is automated and integrated with unit testing then you don’t have to profile yourself, you win a lot of time and can optimize early, and avoid architectural problems later on in your project.

Now if only someone could add this functionality to PHPUnit, early optimization would become a cure.