Recommended
More Related Content
What's hot
What's hot (20)
Similar to Onivim 2: Re-architecting for Performance
Similar to Onivim 2: Re-architecting for Performance (20)
Recently uploaded
Recently uploaded (20)
Onivim 2: Re-architecting for Performance
- 1. Bryan Phelps ReactiveConf 2019 Re-architecting for performance
- 2. @bryphe
- 3. Overview 1) What is Onivim? 2) V1 Electron Architecture + Challenges 3) V2 Reason Architecture + Results
- 4. Fast, Beautiful Interface …like Sublime Text Top-Tier Language Support …like VSCode Modal Editing …like Vim
- 5. …fastest way to go from thought to code
- 6. Onivim V1
- 9. Performance Challenge #1 Startup Time
- 12. Renderer Process Neovim Process Key Press Render Msgpack Input Buffer Update Screen Redraw Window Metrics Dimensions Performance Challenge #2 Responsiveness Event Loop Event Loop
- 13. V1 Performance Work Startup Runtime • Bundle Splitting • Async Imports • Minification • Typing prediction • Debounced rendering • Split Redux stores • Paint profiling Always could do more…. but diminishing returns.
- 14. React Application Code Chromium Node Harfbuzz FreeType Platform APIs NPM Modules Neovim Typing Prediction Bundle Splitting Electron V1 Architecture
- 15. React Application Code Chromium Node Harfbuzz FreeType Platform APIs NPM Modules Neovim Typing Prediction Bundle Splitting Electron V1 Architecture
- 16. React Application Code Harfbuzz FreeType Platform APIs Neovim Typing Prediction Bundle Splitting V1 Architecture Native Dependencies
- 17. React Application Code Harfbuzz FreeType Platform APIs Synchronous Vim Typing Prediction Bundle Splitting V1 Architecture Native Dependencies
- 18. React Application Code Harfbuzz FreeType Platform APIs Native Dependencies Synchronous Vim Ideal Architecture
- 19. FUNctional UI UI = ƒ(state) ...without all the extra layers!
- 20. How do we get there?
- 22. • Built by the creator of React • Functional Language • JavaScript-like Syntax • <JSX /> • Compiles to native code Reason
- 23. • Built by the creator of React • Functional Language • JavaScript-like Syntax • <JSX /> • Compiles to native code ReasonML • Built on OCaml
- 26. • UI + Application Framework • React-like concepts • Compiles to native code • Desktop-only
- 29. Revery: Examples
- 31. V2 Architecture Onivim 2 libvim VSCode Extension Host Native Reason Revery Node
- 32. Startup Time Memory Usage Onivim v1 0.37.0 ~5s ~250 MB Onivim v2 master ~0.5s ~50 MB Performance
- 33. Demo
- 35. Thank you! @CrossR @glennsl @szbergeron @KevinSjoberg @jordwalke @andreypopp @ulrikstrid @def @bendersen @kyldvs @wokalski @manuhornung @prometheansacrifice @jchavarri @Et7f3 @lessp …and all our backers and pre-orderers!
- 37. Thank you! • Website: https://outrunlabs.com • Pre-order: https://onivim.io • Twitter: @bryphe / @oni_vim
- 38. @bryphe ReactiveConf 2019 Re-architecting for performance
Editor's Notes
- Hi ReactiveConf! My name is Bryan Phelps, and I’m really excited to be here today to talk to you about a code editor I’ve been working on called Onivim. I’m going to share with you today how we re-architected for performance, and not only is it faster, but we were able to get a cleaner application architecture out of it, too!
- I’m the founder of a company called outrun labs. Before that, I was working at Microsoft on a variety of cross-platform and web applications. You can find me on twitter / GitHub / discord as @bryphe.
- Here’s an overview of what I’ll be discussing - First, I’ll give you some quick background on Onivim - just enough so we can talk about the architecture. Second - I’ll describe our v1 architecture and the challenges we faced. Finally, I’ll talk about our v2 architecture
- So what is Onivim? It’s a code editor - but kind of a niche one. It aims to combine a few different worlds. Modal editing, like Vim. A modal editor is one that has different “modes” - insert mode is the one we’re used to in every editor from notepad, word, but modal editors have modes specifically for editing and navigating text with just the keyboard. A fast, beautiful interface - I think Sublime Text is the gold standard - it shows you can have a GUI that’s fast and performant. Top-tier language support, like VSCode The vision for Onivim is to take these ideas - bring them together - and ultimately, to be the fastest way to go from thought to codeAlthough there is still a lot of work left - I think our v2 is positioned architecturally to get us there.
- I want the fastest way to go from thought to code. A tool works for me, always keeps up, that never makes me wait or takes me out of the flow. It’s been a journey and we’re not there yet - but for this talk, I’d like to take you on that journey with me and share some my thoughts and learnings. Hopefully, even if you’re not interested in editors or Vim, the architecture pieces will still be interesting. So let’s rewind a bit and talk about the start of the project - our v1.
- This is a screenshot of our V1, and it’s really the same goal and vision… We shipped our v1 as a cross-platform Electron app that met some of these goals. Really the most important outcome for our v1 was I found there was a group of developers who were also interested in this hybrid. We also experimented with some fun ideas - like modal editing and Vim have a deserved reputation for being hard to learn - how can we make that easier? But it wasn’t perfect. In particular, we struggled with performance. It’s cool to hate on Electron on hacker news and stuff, but the reality is, there were issues that kept us from meeting that goal of being the fastest way to go from thought to code. The target audience - vim users - have a very high bar for performance. We sort of pursued more and more investments to get the performance that we wanted. We also had bugs around non-determinism with key presses - the worst kind of bugs you can have in an editor - and there was a lot of asynchronicity in our architecture that was complex to manage. It was really these combination of issues that led me to think about what an alternative architecture could look like. But let’s take a look under the hood at the tech stack of our v1
- Electron applications have a main process, which is like an orchestrator, and one or many renderer processes, which manage windows. We also had an extension host node process for running JS plugins, and we used an open-source project called Neovim to handle the Vim-layer modal editing for us. More information on Neovim: https://neovim.io
- Let’s zoom in our renderer process. Inside there, we used a Redux store, we used React for most of the UI, but for the editor surface we used WebGL. I really like this stack for web applications. Redux + React is kind of a gateway drug to functional programming. And for all the hate Electron gets, the reality is, it’s never been easier for a small team to ship a cross-platform application, and there’s a lot of value in that. I think the most powerful feature of Electron is not only that its cross-platform, but you can develop cross-platform with confidence - what I mean by that, is I can write my Electron app on one platform, and as long as I don’t use a narrow set of platform-specific APIs, I can be pretty sure it looks and feels the same everywhere and sort of an inherited benefit from the web platform.
- However, there were challenges, otherwise this talk wouldn’t be happening. As we built more and more, the application would get slower to start. And I realized - you don’t really appreciate all that the browser or a JS engine is doing for you - until you profile. So let’s check out the profile.
- So the timeline starts at 0.5 seconds - 500 milliseconds. And takes about 3 seconds total to start the application. For the first second, we’re not rendering anything - just an empty screen. From there, we finally see a titlebar at the 1 second mark. Then, we start see some UI, but it’s not quite done… we see a brief pop-in of a menu, and then finally our UI is ready. A second is literally billions of CPU cycles on the hardware I grabbed this profile - an intel i5 - so what is doing with all those cycles? Well, a lot of loading JavaScript! Our first couple scripts each take around ~300ms to parse and evaluate. The JS engine actually has to load, parse, and it might decide to leave as byte code or go even further to JIT at this time. It’s a lot of work, and it’s a testament to JS engines how quickly they manage to do this. But it is still an appreciable cost. And coming from languages that C or C++ that are compiled… it’s kind of crazy to me - I’m actually compiling the code with TypeScript, so why does it need to compile again when I run it? I look around at other applications for inspiration - Vim starts up instantly. Sublime text starts up instantly. Why can’t my app startup that quickly? To me and my users even 2 seconds is too long.
- Aside from startup performance, there were several other performance challenges. The main challenge on my mind was responsiveness. Responsiveness is the time from processing user input to showing the result on screen. Ideally, we should shoot for a maximum of 16ms - which is one frame at 60 frames per second. Games render at this rate, entire 3D scenes - why shouldn’t our editor be able to do that too?
- Onivim v1 used Neovim to basically do all the heavy lifting of text manipulation for us - we’d send it a key input, it would get put on an event loop, and we’d get responses back from Neovim - both a list of what changed in the buffer, and what to redraw on the screen. A specific challenge we had was overhead around asynchronicity. We’d have a key press come in, and then we’d send that to Neovim. Beyond that, we wanted to render additional things in our buffer - rich adorners, color widgets, minimap, tab indents, and to do that, we needed to know more about the window dimensions. This required at least one but usually more calls to help us map from a buffer position (line and column) to a pixel position on the screen. And we needed to do all these calls within a frame. Our measurements showed some jitter - usually they’d complete in 1ms, but sometimes more… and we’d run into situations where it’d be easy to miss a frame. Oh, and at the end of all that, we’d have to actually render, which isn’t trivial - and we can’t manage things like sync in the browser.
- We actually worked hard on performance. For startup, we did a lot of the recommended things: Bundle splitting - so that we don’t have to load all the javascript at once. We can defer some of it. Async imports - so we could parallelize the JS loading with other operations. Minification - helps to minimize the work the JS parser has to do - less characters == less work! For runtime performance, we did a lot too: -Keystrokes would be sent to a separate process - Neovim - to be handled and come back with an update for the screen. We implemented a ‘typing prediction’ to guess what the result of a keypress would be so we could render immediately. This added complexity though in cases where we guess ‘wrong’. — We debounced our Redux stores so that updates only came during animation frames. Before that, every state change would trigger a DOM change. We split up our Redux stores, to reduce the cost of processing updates. We had a big enough state and enough of actions that just the overhead of cloning the JS objects showed up on our profiler. And it’s true that we stopped short of a few potential optimizations - like pre-compiling byte code for startup. As a very small team, you reach the point of diminishing returns. And I could see additional incremental gains, but not the instant performance that myself and my users want. In the back of mind, I was thinking - why do we have even have to battle this? Why can’t our desktop app, our technology, be fast by default? Why is it that we have to work so hard to get startup performance to a couple seconds… when older apps like SublimeText or Notepad++ startup instantly?
- And if I look at our architecture from another perspective - the layers - this is what it looks like. At the bottom - the foundation - you have platform APIs. On top of that - if you’re using a tool like Electron - you’ve got Node, Chromium, Neovim. Tons and tons of npm modules - until you get up to React, Redux, and then finally, your application code. And on top of my application code - in red - is what I’d consider accidental complexity. Things that aren’t core to the application, but stuff we had to get acceptable performance.
- What could we do about it, though? Well for one… we’re using WebGL anyway, why not just cut out the middle-man and remove Electron? We could just use OpenGL directly, or a wrapper like Angle.
- If we get rid of Node and Chromium for our core editor, well, we have to figure out we’re going to do with React and NPM dependencies. Hopefully we could replace them with a streamlined set of native dependencies - but preserve the React paradigm.
- I also wanted to switch out our input handling to be synchronous, so that we can have better performance and avoid the challenges of synchronizing state across async boundaries. So I wanted to replace our current ‘neovim’ with some sort of Vim state machine that I could feed input and it would handle it synchronously. Finally… I wanted a tech stack that wouldn’t require me to add all this accidental complexity at the top of this stack to get the performance I wanted.
- So I kind of went Konde Marie on the stack, streamlined it, and end up with what would be my ideal architecture, for our desktop app. What I want is a way to have the React paradigm…. But without any JavaScript. This could help our startup time tremendously if we could somehow didn’t need to do that parsing. Finally, if we had a synchronous model for handling input where we process the input and render immediately without asychronicity - we can meet our responsiveness goals and simplify our state management.
- I wanted to keep this React paradigm of your UI as a pure function of your state, just with a more streamlined stack - because I think its great to work with (and… your state as a pure function of your previous state and action).
- How do we get there? That was really on my mind. And I didn’t have the answer, in fact, I considered just putting the project on hold, because I didn’t think we could meet our goals with the current tech stack… I thought about switching to C++ or Rust and using a UI framework there - it is a desktop app - maybe Qt— but I’m stubborn, and I’d miss that React-style UI development.
- It just so happened, around this time, I learned about an exciting project called Reason.
- It’s built by the creator of React - Jordan Walke - imagine if you had a language built for React. It’s a functional language, but it’s pragmatic - you can do imperative, even OO, have mutable objects, although its geared and optimized for a functional approach - but it means you can be productive quickly without needing to climb an ivory tower of monads and category theory. It looks like JS, has JSX, and importantly for me… compiles to native code.
- (bullet points) It’s actually not a new language… it’s essentially a wrapper around a language called OCaml, which has been around for a while and has investment from companies like JaneStreet. This ‘compiles to native code’ aspect is really what can save us on startup performance. Recall from my performance profile - so much time was spent evaluating JavaScript. Well with native code - there’s no evaluation step - you compile directly to machine code!
- Around December last year, we started prototyping - what could this editor look like built on Reason? And this was the very first screenshot we had of the prototyping of our V2. It’s so ugly, the text rendering is horrible, no gamma correction… but we had all the pieces we needed. It makes you appreciate what Electron does - a mature framework on a mature platform, the browser . We could render text, we could render rectangles, and even icons. All the ingredients for a code editor, the rest is just details.
- Revery is a UI and application framework, built on Reason, with React-like concepts, that compiles to native code. It’s desktop only for now, the main use case is for Onivim 2, but we’d like branch out to mobile. Let’s take a look at some more code.
- This is the simplest, smallest Revery app - simply opens a Window, and renders an empty view. If you squint, it almost looks like JavaScript - but this compiles to native code. The `App.start` is the entry point, and takes a function that gets passed an app instance. You can think of that like ReactDOM.render, just for a native application. And with that app instance - you can create a window, and with that window, you can create a UI. `UI.start` is a lot like `ReactDOM.render` just a native rendition
- This is a snippet of source code from our prototype - and this is the top level UI component. It looks a bit like React - you have compassable components. We realized some of this stuff could be more general, so we factored it out to a UI framework called Revery.
- These are a few other apps built with Revery: Revery examples: https://github.com/revery-ui/revery Chesster by @kyldvs: https://github.com/kyldvs/chesster Camlsynth by @kenwheeler: https://github.com/kenwheeler/camlsynth
- So we took Revery, doubled down on our functional approach, and continued building, and we’ve been making steady progress building an app on this stack. It’s still ‘pre-alpha’ but we’re moving forward.
- The architecture we landed on was a fast, native code front-end built with Reason. This uses Revery for the UI and application life cycle. We also created a library for Vim, called libvim, which is agnostic of the terminal, and has a synchronous API. Vim itself has a blocking API for input, so we sort of had to invert the input model. Because the front-end is native code, it really solves our startup issue - we don’t need to load and evaluate JavaScript anymore. This is the goal of our next milestone - to wire this up. We didn’t get out of the JS game entirely, because we want to leverage VSCode extensions - so we still have a node process, but in the backend, entirely async. And the protocol is designed to be async so it doesn’t impact our front-ends performance. This is our next big goal, to graduate from ‘pre-alpha’ to ‘alpha’ - isto wire this piece up. But it’s a cool architecture, because we get the benefit of a fast, native front-end while being able to leverage the breadth and power VSCode extensions.
- These are point-in-time, ballpark perf numbers for startup - with a small JSON file. If you didn’t ’t fall asleep yet, you might notice this 5s number is greater than 3.5 s I showed - that’s because it includes other aspects - when you start an electron app, the main process starts first and then kicks off the renderer process - there’s more that happens in the end-to-end flow. The crazy thing though, is there’s lots of low hanging fruit left for us in the native code world - our drawing layer is wildly inefficient, we’re not even using the ocaml optimizing compiler, there’s blocking I/O on our start path… but it’s still faster.
- So I’ll show a quick demo - it’s off master, still very much alpha on this new tech stack- but I’m going to open up oni2’s package.json file and make some changes. Want to try it yourself? Instructions here to build from source: https://onivim.github.io/docs/for-developers/building I’m using my favorite VSCode theme, a theme called LaserWave. Let’s open the key displayer so you can see what I’m doing I’m going to fix this .ccc extension - I can jump down and use the change in quote command to do quick replacement. Now I’m eyeing this ‘esy’ block above… I want to move it. I think this combination of modal editing, first-class language support, and responsiveness is tremendously productive, although modal editing does have a learning curve - and we’re thinking about ways we can lower that.
- Everything I’ve been building is standing on the shoulders of others - there is so much great work happening in the OCaml ecosystem, the Reason ecosystem, and I’ve been tremendously appreciative of all the building blocks and investments others have made. Big thanks to everyone who’s help backed and pre-order the project too and let us dive this deep!
- You can support the project by pre-ordering at https://v2.onivim.io
- And thanks again everyone for being here and coming to my talk!
- Hi ReactiveConf! My name is Bryan Phelps, and I’m really excited to be here today to talk to you about a code editor I’ve been working on called Onivim. I’m going to share with you today how we re-architected for performance, and not only is it faster, but we were able to get a cleaner application architecture out of it, too! ∫∫