On Wed, Feb 18, 2015 at 11:00 PM, Nikita Popov <nikita....@gmail.com> wrote:
> On Wed, Feb 18, 2015 at 8:22 PM, Dmitry Stogov <dmi...@zend.com> wrote:
>
>> I think the AST API shouldn't use "public" properties.
>> Using it, we will have to construct the whole tree of objects,
>> duplicating information from AST.
>> I would propose SimpleXML approach instead - construct object only for
>> node(s) we currently access.
>>
>> So at first we will construct just single object referring to AST root.
>> Then traversing it we will create and destroy objects for necessary nodes.
>>
>> To access children I would propose to implementing ArrayAccess interface.
>>
>>
>> $ast = \php\ast\parse($string);
>> foreach ($ast as $child) {
>> echo "\t" . $child->getKindName() . "\n";
>> foreach ($child as $grandchild) {
>> echo "\t" . $child->getKindName() . "\n";
>>
>> }
>> }
>>
>> Thanks. Dmitry.
>>
>
> I've considered using this approach, but decided against it because it
> introduces a lot of "magic" for unclear gains. Lazily creating the objects
> means we have to keep around the entire AST arena while at least one node
> referencing it is alive. So if you're analyzing a large project with a few
> thousand files and keep around a few nodes in some cases, you end up not
> just with the memory usage of those nodes, but with the memory usage of the
> entire ASTs. Furthermore in many cases you'll just traverse the entire AST,
> in which case you'll need to instantiate all nodes anyway and the lazy
> instantiation will only hurt.
>
> In any case, performance of constructing a full AST is pretty good - I
> don't remember the exact numbers, but ast\parse_code() is only slightly
> slower than doing token_get_all() on the same code.
>
I think the whole memory usage should be less, because at each point you'll
most probably keep only few AST objects, but I understood your arguments.
They may make sense, but it's hard to say what is better without comparison
of implementations.
Thanks. Dmitry.
>
> Nikita
>
