| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
as a pilot. Currently not hooked up to anything, but will be shortly.
PiperOrigin-RevId: 165583517
|
|
|
|
|
|
|
| |
Almost all implementations simply return this, all of which can be removed
now.
PiperOrigin-RevId: 163046912
|
|
|
|
|
|
| |
to indicate unserializability, improve error message in Path when serialization fails, and add some test-only methods to SkyframeExecutor and PackageFactory.
PiperOrigin-RevId: 162993806
|
|
|
|
| |
PiperOrigin-RevId: 162715709
|
|
|
|
|
|
| |
wrapper objects: for OwnedArtifacts, which are the most numerous during builds, and for Labels for TransitiveTraversalValues, which are the most numerous during queries.
PiperOrigin-RevId: 154989520
|
|
|
|
|
|
|
| |
are created, as opposed to when they are requested from the ParallelEvaluator. That delay can lead to large memory spikes and churn.
--
MOS_MIGRATED_REVID=116224565
|
|
|
|
|
|
|
| |
Reduces garbage.
--
MOS_MIGRATED_REVID=109914243
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While a normal set is theoretically sufficient, it can cause hard-to-reproduce
problems. In particular, the iteration order of the expansion result depends
on the iteration order of the requested targets. If there are multiple
requests for the same set of targets, but with different orders, the results
would depend on which request was made first. If a downstream function also
inadvertantly depends on the iteration order, it can be hard to debug why it
ended up with a different order than it requested.
Alternatively, we could sort the result before returning it. We generally
expect the key set to be smaller than the result set, so this should be
ever so slightly more efficient.
--
MOS_MIGRATED_REVID=105765514
|
|
This is currently not hooked up, and we're passing (potentially) massive
numbers of targets around.
--
MOS_MIGRATED_REVID=105395404
|