6 ms·

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.