This talks takes us on a journey through the layers of the cake called "Dart". We often hear that jsonDecode is slow in Dart - can we make it faster? Where do we start?
We will look at the Dart core libraries and how they implement jsonDecode. We will take that code for a spin with a profiler and learn how to diagnose performance issues using low-level tools.
A talk about how the Dart Runtime runs Dart code.
This talk is about how the Dart runtime works and how you can figure out low-level performance issues and how to apply optimisations.
A talk about how the Dart Runtime runs Dart code.
This talk is about how the Dart runtime works and how you can figure out low-level performance issues and how to apply optimisations.
Dart (http://dart.dev) might be the only contemporary programming language that changed its core principles so radically between two major versions. 10 years ago, in 2010, it was born as a dynamically typed programming language with optional static types - ideas of Strongtalk wrapped into familiar C-like syntax. A language destined to be executed in a native VM with an adaptive JIT compiler. Yet over the years Dart has evolved into a language with a sound static type system, and is being deployed in contexts that require ahead-of-time compilation and prohibit JITing. Now, it is even trying to get rid of the “billion-dollar mistake” - null - and incrementally transition to non-nullable by default reference types.
This talk focuses on the architecture of Dart Virtual Machine and how it followed the evolution of the Dart language, adapting to the new semantics and new execution environments, where users wanted to bring Dart to.
No matter whether you are developing or deploying your Flutter application it ends up running on the Dart VM. How does Dart VM run your code? Is there any difference between development and deployment configurations?
Learn about all the things Dart VM team is doing behind the scenes to ensure that your applications are fast and slim.
When Dart was originally designed its designers assume that it will primarily execute in a VM with a JIT.
However these days Dart is actually primarily deployed in environments that require it to be compiled ahead of time to native code (mobile) or JavaScript (browser).
This talk covers Dart VM journey from JITing Dart to AOT compiling it and the lessons we learned on the way.
Compiler conferences are always full with engineers and researchers happy to share how they do things.
This talk is a refreshing departure from the trend. I will take a look at my time working on V8, Dart VM and LuaJIT at Google and share with you how we did not do things and why that matters.
Каждый день инженеры-компиляторщики по всему миру увлеченно стучат по своим клавиатурам разгоняя исполнение JavaScript в совершенно различных браузерах и даже на сервере.
Общественность, программирующая на JavaScript, однако же, часто отстает в своем понимании от стремительного прогресса, происходящего во внутренностях JS движков.
Этот доклад старается покрыть отставание и продемонстрировать, что знание этих самых внутренностей важно не только для написания быстрого JavaScript кода, но и просто для того, чтобы достоверно измерить разницу между "быстрым" и "медленным".
This talk summarizes my experience from digging into LuaJIT 2.x sources while working as a compiler engineer for Google DeepMind.
This is not a deep insight into LuaJIT inner design, but rather a collection of choices made by original LuaJIT implementor which I find interesting and educational.
JavaScript performance remains an area of focus for all major browser vendors.
Each day VM-engineers across the globe pump their expertise into JavaScript engines powering client and server-side code alike.
However our understanding of JavaScript engine internals does not always keep up with those internals.
This talk tries to rectify this lag and demonstrate that knowledge of implementation details is crucial not only to writing fast JavaScript code but even to simply measuring the difference between fast and slow.
JavaScript is everywhere. JavaScript VMs improve by leaps and bounds. Performance graphs are breaking through the ceilings of expectations.
And yet from time to time we still find ourselves wondering whether '===' is faster than '=='.
What is the right way to approach this question? Is this the question you should be asking to begin with?
We will take a look at some microbenchmarks written by JS developers and discover a violent clash between XIX century approach to benchmarking and XXI century virtual machines.
The popularity of dynamically typed programming languages has been skyrocketing in the past years. This success can be partially attributed to the advances in VM engineering enabling efficient execution of those languages.
Just like boilerplate of any enterprise application can be decomposed into infamous patterns of object oriented design, efficient virtual machines running dynamically typed languages seem to consist of reimplementations of common patterns of "VM design". These patterns often tread the thin line between efficiency, development time and maintainability.
This talk discusses the trade offs we encountered while building virtual machines for JavaScript and Dart programming languages.
The apple always falls down attracted by the gravity of the earth. It’s the law of physics. The function is never inlined if it’s source is bigger than 600 characters long. It’s a heuristic - a physical law of our dystopian cyber-world confined inside a JavaScript Virtual Machine.
Ever wanted to rebel against the sad immutability of the physics? Lets try to make functions fall upwards and inline all the apples.
In an ultimate attempt to create a space-time paradox that will rip our universe apart we will look at Java programmers implementing JavaScript on JVM through invokedynamic and then will implement invokedynamic in a JS VM instead.
The true freedom is just one heuristic away..