a1bf0974ce
### Pull Request Description Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`): - `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`. - `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental. (See key in first chart for the settings defining these profiles.) We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes: - `release`: A profile that supports fast developer iteration, while offering realistic performance. - `production`: A maximally-optimized profile, for nightly builds and actual releases. Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags. ### Performance details  As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster. <details> <summary>Methodology (click to show)</summary> I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data: Build the application with profiling: `./run.sh ide build --profiling-level=debug` Run the `open_project` workflow repeatedly: `for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done` For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV: `echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do` (Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...) The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data. </details> #### Build times  In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds. (To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.) |
||
|---|---|---|
| .. | ||
| analytics | ||
| config | ||
| controller | ||
| docs | ||
| enso-profiler-enso-data | ||
| language | ||
| src | ||
| tests | ||
| view | ||
| Cargo.toml | ||
| config.yaml | ||
| LICENSE | ||
| README.md | ||
This is the subtree for Enso's graphical interface component. If you're looking for the repository root, you may find it at at 👉 github.com/enso-org/enso 👈
Enso IDE
Overview
Enso is an award-winning interactive programming language with dual visual and textual representations. It is a tool that spans the entire stack, going from high-level visualisation and communication to the nitty-gritty of backend services, all in a single language. Watch the following introduction video to learn what Enso is, and how it helps companies build data workflows in minutes instead of weeks.
This repository contains the source code of Enso interface only. If you are interested in how the interface is build or you want to develop it with us, you are in the right place. See the development and contributing guidelines to learn more about the code structure and the development process.
Getting Started
Enso is distributed both in form of pre-build packages for MacOS, Windows, or Linux, as well as the source code. See the demo scenes, and read the documentation to learn more.
Building
The project builds on macOS, Linux, and Windows. Build functionality is provided
by our build script, that are accessible through run (Linux and macOS) or
run.cmd (Windows) wrappers.
To build the project, simply run ./run ide build (on Linux or macOS) or
.\run.cmd ide build (Windows) to build IDE. To learn more about other
available commands use --help argument. Read the detailed
development guide to learn more.
License
The Enso Language Compiler is released under the terms of the Apache v2 License. The Enso Graphical Interface and it's rendering engine are released under the terms of the AGPL v3 License. This license set was choosen to both provide you with a complete freedom to use Enso, create libraries, and release them under any license of your choice, while also allowing us to release commercial products on top of the platform, including Enso Cloud and Enso Enterprise on-premise server managers.
Contributing
Enso is a community-driven open source project which is and will always be open and free to use. We are committed to a fully transparent development process and highly appreciate every contribution. If you love the vision behind Enso and you want to redefine the data processing world, join us and help us track down bugs, implement new features, improve the documentation or spread the word! Join our community on a Discord chat and read the development and contributing guidelines.
