I understood that I was talking about running speed. So the answer is that should not consider performance for micro-optimizations. Understand that languages do not have speed. At most they have philosophy that makes it easy or does not have speed. Implementations already have a little more. But not so much. Often the performance is in the library used.Something punctual in PHP is possible faster than Java. Why? Java has few, but some costs that a lower level language, like C, has. If a PHP function can be written in C, and many of the default library are, and you don't have to get accessing the virtual PHP execution machine a lot, it's possible that this function can be faster as long as the function is very well written. I'm talking about thesis, in practice I don't see this happening much.PHP can run faster and faster https://pt.stackoverflow.com/q/214519/101 can improve. Today less, because PHP implementation has improved a lot. It has several tools that help. But she has other issues that cannot be resolved without language becoming something else. In PHP 8 it will improve more.Here is a cruel truth that many PHP amateurs (yes, they love the language) hate to hear: people involved with the development of language are not the best engineers in the world, do not have a theoretical basis of very suitable languages, and have taken a complicated legacy, outside that do not have the necessary resources to create an extremely fast language.Note that the benchmarks that show improvements in PHP disregards the load that has gotten much worse by pre-compiling and optimization. When it compares the whole, where PHP is used the whole is much more important than in other types of application, the gain is not that big. Never forget that people who like or produce a technology will use measurements that best meet your needs marketing, which is legitimate, just don't lose sight of it.I believe that when they say that PHP does not focus on its performance, would it be compared to other languages/technologies?Yes, it always has to be comparing with other languages. But no one said that PHP is the slowest language that exists. And it improved. PHP is faster than Ruby (default and current implementation), faster in some things than Python, gains in some Moon points (although LuaJIT no longer occurs), and loses ugly to JavaScript (NodeJS to compare with backend). It does not come close to almost everything when the comparison is with C/C++, C#, Java, D, Rust, Delphi, Go, VB.NET, F#, etc.Would that be about PHP being a interpreted language?One of the main reasons. But also for having dynamic typing (probably the biggest reason in longer executions), so everything has to be checked internally before running. Some optimizations are not possible because of this, and because it is also interpreted.Also for having mechanisms all. Essentially has no diverse data structures, has the array soothing and serving for everything. It even has different structures, but they are terribly implemented.It has a number of misleading decisions that make language not have the performance it could.Think you have a load, a preparation of the environment and the compilation of the text to then perform.Only PHP or all languages interpreted or correlated?All who follow the same philosophy. It is not possible to beat the performance of a code generated by a good compiler and that "all" is solved in compilation time.It is possible to make interpreted languages have a very interesting final execution and in some cases even to beat compiled languages. But it is extremely difficult, costly and the better the result of worse execution will be the load time. Running script this tends not to compensate much. https://pt.stackoverflow.com/q/143708/101 is PHP compiled and static typing, it is much faster. But it could be more if you didn't want to maintain good compatibility with PHP.This is said because PHP has not been done to be fast. Simple like that. PHP was created to be easy and have fast delivery, opening performance hand, which in web applications is not critical. If you need performance don't use PHP, as well as if you need to hammer a nail, don't use a pliers.I agree with the general idea, but web performance is just not critical to very simple things. Which makes every sense to use PHP. But it doesn't make sense to make OOP with PHP.When it's a lot of access, it has a lot to do, performance is critical at the cost of maintaining infrastructure that can handle something slower. Worse can still need extremely more complex solutions to distribute the work, and this costs very expensive. People don't even realize they're paying more expensive than they should. Or they don't need the technology they're using.I'm not even talking about the cost of opportunity that is to lose a user because it took to respond.Forget PHP performanceObviously this is worth micro-optimization. PHP benefits from macro gains. Choosing the way to do can give interesting gains.Why not focus on PHP performanceBecause the gain will be small and the cost will be huge. The language does not help gain performance and has cost that does not have what to do that inda will be the thick of the run time. In some languages it is possible to win in 80, 90% of the code path. In PHP it usually gives a maximum of 50, 60%, often less.Also because most websites have little access and do not need this gain. Just because having little access doesn't make up spending much on it. Giving performance costs more expensive.a project that makes access to a database will have access time to the bank much longer than the running time of the PHP codeThis is not always true, especially in PHP codes because it is common for the programmer of this language not to understand all costs. If it does something complex in PHP that could be done in the database, and I see it occurring too much, in PHP it will cost more expensive than in C# or Java.Now, one important issue is that PHP almost invariably accesses database. There are other languages that are not. When you don't have IO the performance gain is more important. In fact IO generates a cost that makes less relevant performance gains.To answer stay complete I need to quote Isac's comment:most of the issues of "How can I improve the performance of this?" focus on micro almost always irrelevant optimizations for the scenario in question. Things like "using a variable more or not in this case or not?
