https://bugzilla.wikimedia.org/show_bug.cgi?id=29784

--- Comment #10 from Brad Jorsch <[email protected]> ---
(In reply to comment #8)
> To investigate this, I added the following line to the bottom of
> jsminplus.php:
> 
>     JSMinPlus::minify( file_get_contents( $argv[1] ) );

Note this is actually going to be using less memory than what ResourceLoader
actually does. JSMinPlus::minify passes itself to the JSParser constructor,
which causes it to trim the node tree for the body of each function.
ResourceLoader passes null, so this isn't done.

We could easily enough get that advantage in RL by passing JSParser an instance
of this:

  class DummyMinifier {
      function parseTree() {
          return null;
      }
  }

If we really want to cut the memory usage, though, we could add a mode to do
the same sort of pruning even more aggressively, maybe on every statement
instead of only on every function body.

> On #wikimedia-operations, Azatoth was trying to reproduce these measurements,
> but memory consumption on his machine was much lower: around 35 megabytes. He
> is running PHP 5.4.4-14+deb7u1. I upgrade a test machine to
> 5.4.15-1~precise+1
> to see if perhaps the underlying cause was a memory leak that had been fixed
> in
> PHP. With that version, memory usage went down to 127 megabytes -- much
> lower,
> but still very high. I don't know why Azatoth was getting such different
> results.

Me neither. On my local machine, with Debian's 5.4.15-1, I get around 42M.

> I think there's a bad leak in jsminplus.php, and my hunch is that it has
> something to do with keeping references to substring copies of the input
> buffer.

It looks like the problem is just that jsminplus builds up a huge tree of
JSNode objects (i.e. 86487 of them). Dumping this tree doesn't show copies of
the input buffer.

However, I do see that it makes temporary copies of large substrings of the
input buffer very often, because it treats "no comment" the same as "comment
longer than $chunksize" for some unknown reason. This can be reduced by adding
the following check just before line 1864:

            // If it's not possibly a comment (or regex), exit the loop
            if ($input[0] !== '/')
                break;

Even though these temporary copies are soon freed, they still cause memory
usage spikes. Although even after making this change, XDebug seems to be
reporting that PHP is still allocating 128K memory buffers associated with
calls to JSTokenizer::get for no obvious reason.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to