cueckoo
commented
3 years ago Original reply by @mpvl in https://github.com/cuelang/cue/issues/630#issuecomment-757138083
I've just checked in a series of CLs that should add another big performance boost. For some larger configurations this let to about a 95%!r(MISSING)eduction in run time. Moreover, though, these CLs allow for a host more of improvements that will lead to better runtimes and memory consumption.
Things still to do:
- use merge sort for sorting Arcs
- special-case list processing
- push-based, instead of demand-based updates
- reduce size of Vertex
- don't fully process fields if it is not strictly necessary:
- while evaluating disjuncts, stop processing on error
- when evaluating definitions, just do enough to collect conjuncts.
- stop processing disjuncts when it is known they cannot become concrete
- discriminator fields
- various other control flow optimizations
- optimize boolean computation
- special-case arithmetic of small numbers
- less memory allocation
The main order of business now is avoid the big slowdowns. Really the best way to help there is to come with complete reproducers to reproduce any performance issues.
Originally opened by @verdverm in https://github.com/cuelang/cue/issues/630
Several of us have brought up runtimes as an issue, either with our own work or something that could hurt adoption. This is a large topic that will be addressed by several efforts with time, so some patience is warranted. I'm starting this thread to capture the various discussions.
Marcel (@mpvl) has put exceptional effort into Cue and we should recognize this first. We owe you many thanks. Marcel is also the most knowledgeable about and the primary implementor of the algorithmic side of the answer to performance issues. Part of the goal here is to help him understand where the issues are.
There are two main ways to look at understanding performance issues:
I believe we should sideline (2) for the time being as the guidance will likely change as we address (1).
Insofar as (1) is concerned, we can note the following:
Benchmarking (via the Go tool) has not been implemented yet. This is a good first step. We have been mentally building a list of known issues and we should start collecting them in the repository. We will likely want to benchmark at both the function level and by looking at complex configurations run by the tool, though we likely don't want to include large configurations that are more typical in the wild.
Beyond benchmarking, we will want a way to help users identify and report issues with their own Cue. Some things that come to mind here:
A. Enable Go's perf tools from the Cue CLI / API B. Expose some Cue logical level statistics from the CLI / API a. Marcel has some stats objects in the evaluator that could be printed (?) b. Some higher level stats like input / output nodes C. Have some documentation on the above and how to contribute benchmarks for the repo
I'll leave it there for now and look forward to your additional insights. Please correct me anywhere I have misspoken.