# Compiled variables and backpatching - Thread: https://externals.io/message/32425 - Original archive: https://news-web.php.net/php.internals/32425 - Started by Paul Biggar on 2007-09-23T15:46:45+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #32425 — Paul Biggar — 2007-09-23T15:46:45+00:00 URL: https://externals.io/message/32425#32425 Hi, I'd be very interested to have an overview of compiled variable and backpatching within the interpreter. I can find plenty of emails and code that refers to the two topics, but none that defines them. If there is an overview somewhere, could somebody point me to it? If not, I have a few questions. Answers of any length are appreciated. What is a compiled variable? How does it differ from a non-compiled-variable? Why were they introduced? I presume that this is for performance - what performance impact do they have? What is backpatching? Is it related to compiled variables, or are they different concepts? Why was backpatching necessary? Is this performance related, and what performance impact does backpatching have? Thanks in advance, Paul -- Paul Biggar paul.biggar@gmail.com --- ## #32427 — Stanislav Malyshev — 2007-09-23T19:00:14+00:00 URL: https://externals.io/message/32425#32427 · In reply to: #32425 > What is a compiled variable? > How does it differ from a non-compiled-variable? When engine encounters variable like $a what it usually does is it looks up current symbol table for an entry named 'a', and then takes zval* sitting there. However, since during the same scope the entry for $a will be the same (though not a value sitting there!), once found in can be stored so future calls to $a will not require looking up in the hash table. That's what CVs do. The reason, of course, is performance :) -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #32428 — Paul Biggar — 2007-09-23T19:28:14+00:00 URL: https://externals.io/message/32425#32428 · In reply to: #32427 > > […] > > When engine encounters variable like $a what it usually does is it looks > up current symbol table for an entry named 'a', and then takes zval* > sitting there. However, since during the same scope the entry for $a > will be the same (though not a value sitting there!), once found in can > be stored so future calls to $a will not require looking up in the hash > table. That's what CVs do. The reason, of course, is performance :) OK, so its a bit of caching. So it sounds like it stores a pointer into the symbol table, so that if $a is redefined it will still be correct. What happens if the symbol table must be rehashed? Does it still work, or does it look it up again? Is there a single CV for each $a in a scope, or is there one per bytecode operand? In other words, in a function which uses $a a lot, does it look it up for each bytecode which uses $a, or only once for that function? Thanks for the quick response, Paul -- Paul Biggar paul.biggar@gmail.com --- ## #32460 — Stanislav Malyshev — 2007-09-27T00:49:50+00:00 URL: https://externals.io/message/32425#32460 · In reply to: #32428 > OK, so its a bit of caching. So it sounds like it stores a pointer > into the symbol table, so that if $a is redefined it will still be > correct. What happens if the symbol table must be rehashed? Does it > still work, or does it look it up again? I think rehashing doesn't matter since hash table has pointers, not actual zvals, and so does CV - so rehashing just moved pointers around, and actual zvals still reside in the same place. > Is there a single CV for each $a in a scope, or is there one per > bytecode operand? In other words, in a function which uses $a a lot, > does it look it up for each bytecode which uses $a, or only once for > that function? Each name has own CV, so that every time you say $a in same op-array it would be same CV. CVs are local per op-array - $a in two different op-arrays are different CVs, and local per function run - i.e. if the same function is run twice, $a has the same CV but values in this CV would be different, so you need one lookup each run. So if the function uses $a a lot, CVs would save all lookups except the very first one in each function run. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #32510 — Paul Biggar — 2007-10-01T11:20:29+00:00 URL: https://externals.io/message/32425#32510 · In reply to: #32425 Hi, Stanislav wrote me a very useful reply to my CV questions. I wonder if anyone has time to give me a quick note on backpatching, and what that is? > What is backpatching? > Is it related to compiled variables, or are they different concepts? > Why was backpatching necessary? > Is this performance related, and what performance impact does backpatching have? Thanks a lot, Paul -- Paul Biggar paul.biggar@gmail.com --- ## #32518 — Stanislav Malyshev — 2007-10-01T17:58:58+00:00 URL: https://externals.io/message/32425#32518 · In reply to: #32510 > Stanislav wrote me a very useful reply to my CV questions. I wonder if > anyone has time to give me a quick note on backpatching, and what that > is? I think backpatching refers to updating past opcodes (i.e. opcodes for code that was already parsed) when they need something that would be known only in the future. E.g., if you have if/else statement, then when if condition is false you need to jump to else, but else was not parsed yet - so when we parse if, we create opcode, but then update it when we parse else so that it jumps to the right place. Also backpatching is used to compose variable expressions - like $foo[$bar]->x->$y->z. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com