5 ms·

So the short version is "PHP doesn't perform optimizations so I had to manually include them".

• canadaj 12y ago
  Sure looks like it to me. Compiler can't figure out how to replace 'true' with '\true'? Better do it myself.
  • Implicated 12y ago
    I stand corrected. Compiler.
    • kyberias 12y ago
      Compiler.
      • alayne 12y ago
        You should not be getting downvoted. The article is clearly discussing the compiler. Compilers and interpreters are not mutually exclusive. Just because a compiler produces bytecode (virtual instructions) instead of machine instructions (like x86), doesn't somehow make it not a compiler.
        • astrodust 12y ago
          Exactly. A compiler transforms abstract source code into machine-readable instructions. These machine-readable instructions can be executable directly, but not necessarily. Is a cross-compiler not a true compiler because you can't execute the resulting code directly? Not at all. So by the same token, one that produces byte code is no different.
          • kyberias 12y ago
            I'll argue with myself here a bit if you allow... When considering PHP, we can think of The PHP Interpreter as a hybrid of two components: 1) a translator/compiler and 2) a bytecode interpreter. Therefore, when someone says "PHP Interpreter" he may indeed refer to that hybrid. If this is true, it would cause these kind of confusions. ;)
            • astrodust 12y ago
              Yeah. I'd suggest that most "interpreters" today consist of a compiler and a virtual machine that runs those instructions. Historically, the earliest interpreted languages had a parser which immediately executed whatever it discovered, like BASIC, where each line was an independent statement that was parsed and executed. It didn't take long for this to prove itself to be terribly inefficient.
  • Someone1234 12y ago
    In the context there was no compiler, there was an interpreter. PHP compilers (which do exist) might remove this type of redundancy, the PHP interpreter likely won't for reasons stated elsewhere in the comments.
    • kyberias 12y ago
      But doesn't PHP compile the source code into byte code and then interpret that? The problem described here was in the _compiler_ part of PHP, not in the byte code interpreter.
      • jiggy2011 12y ago
        Why is this downvoted? it is a reasonable question.
        • mackal 12y ago
          Because its more aruging about semantics than anything else. At the end of the day, it needs to do this in real time and optimizing would cause a loss of speed for sometimes faster executed code, but since it all counts every time, it would be a waste.
          • jiggy2011 12y ago
            Opcodes can be cached until the source file changes. There may be specific instances when caching cannot happen, but the poster seems to not be clear as to why that would apply in this case, hence the question.
      • Someone1234 12y ago
        All of which needs to occur after the user makes a request but before the request is returned. Regardless of which word you wish to use (compiler, interpreter, lexer, etc) or which part of the process you wish to shift the workload into, that work (finding redundancies and removing them) is still being performed in real time after a request arrives (i.e. a user has to wait while we do this). If the redundancy check costs more than the redundancy itself then removing them is utterly fruitless. The only way to avoid that is to take it out of that pipeline (i.e. pre-optimise the PHP OPCodes before a request arrives). PHP pre-compilers and other optimisers absolutely exist and are readily used (e.g. HipHop). Within which case it might not matter if you used GOTO or While(true) as they'd both likely get optimised down to the GOTO OPCodes. However if you're using the original PHP interpreter then leaving them in might be the most optimal/cheap path to follow.
• kstrauser 12y ago
  That whole thread made me cringe. Yes, it's a clever microoptimization, but he never mentions whether a profiler showed it to actually be beneficial. That might save 5 cycles out of a billion, for instance, at the cost of making the code "weird". Don't try to out-clever the compiler. You might be able to do it, but there's no guarantee that tomorrow's compiler update won't be smarter than your today's workaround, leaving you with code that is both "weird" and slow.
  • Crito 12y ago
    > "there's no guarantee that tomorrow's compiler update won't be smarter than your today's workaround, leaving you with code that is both "weird" and slow." Yeah, there is no guarantee, but let's be realistic here. That bug for PHP's incorrect parsing of octal integer literals has been unfixed for what, a decade now?
    • kstrauser 12y ago
      Point taken.
  • ajanuary 12y ago
    > Don't try to out-clever the compiler. You might be able to do it, but there's no guarantee that tomorrow's compiler update won't be smarter than your today's workaround, leaving you with code that is both "weird" and slow. I think that's definitely true in the general case. However, for a 19 line library whose focus is "fast retrying" where the goto construct is "goto beginning of function", I don't think it's really hugely "weird". In this case it's also extremely unlikely to get slower.
    • kstrauser 12y ago
      > However, for a 19 line library whose focus is "fast retrying" where the goto construct is "goto beginning of function", I don't think it's really hugely "weird". Fast retrying of network operations, generally. This optimization should save a few nanoseconds per call to a network service that might take a few hundred or thousand milliseconds. When the payoff is so vanishingly tiny as to be immeasurable, I'd take idiomatic code over clever interpreter-specific optimizations any day.