tree 50bdabf7602f2da7f6d5a3f321ace389557a67c4
parent 4ccabd395a591e85abf108b757f994c184b87d61
author Nathan Harmata <nharmata@google.com> 1489512132 +0000
committer Yun Peng <pcloudy@google.com> 1489521122 +0000

Fix inadvertent performance regression introduced by the recent rewrite of 'blaze query'.

The "streaming" callbacks used by some query functions, e.g. 'deps', make calls to QueryEnvironment#buildTransitiveClosure.

For a cold blaze server, these calls do package loading via LabelVisitor (which calls into Skyframe via a top-level #evaluate call). So we'd prefer a single massive call which can make full use of blaze's loading-phase parallelism via Skyframe over a bunch of sequential small calls.

For a hot blaze server, there are two problems:
(1) LabelVisitor's meager up-to-date check isn't useful (as in we cannot reuse old visitations) when we do a whole bunch of small visitations instead of one massive one.
(2) The actual work of the LabelVisitor (building up a portion of a temporary graph) isn't being effectively parallelized when we do it sequentially in small chunks.

This issue is yet another subtle reason why the old BlazeQueryEnvironment#eval made sense (and why it was unfortunately not compatible with the streaming query evaluation model from the beginning).

--
PiperOrigin-RevId: 150081619
MOS_MIGRATED_REVID=150081619