Sunday, January 12, 2014

mgwt / gwt running on a the Tesla Model S

If you come the Silicon Valley these days you will spot Teslas everywhere, but not here in Germany. A couple of days ago I saw my first Tesla driving around in Munich, being a car nut I immediately needed to get my hands on one here.
I actually would like to replace my old BMW 5 series with something new and I was favoring a BMW M5 very much. When talking about cars in the US, I was always telling colleagues that a Tesla would not work in Germany for two reasons:

  • You will run out of battery on a german autobahn pretty soon, since driving high speeds is very energy consuming.
  • It does not have enough top speed (only 210 km/h)

Tesla just solved the battery problem by offering battery swaps as well as extending their super charger network. Today I can already drive from Munich to Dusseldorf without problems and this network is growing rapidly. Having the battery swaps means that you do not need to care about range anymore since getting new energy will only take 90 seconds.
The oomph that is provided by the performance plus version with its 600 Nm is quite exciting to drive, but it is still lacking in max speed. If I spent 125 thousand euros on a car, I expect it to at least go 250 km/h or even more. A BMW M5, a Porsche 911 turbo, Mercedes AMG 63, all these cars can easily hit 300 km/h on a german autobahn. This is not a theoretically number, people actually drive this fast in Germany. This is still a problem for Tesla in Germany, but other than that I would now prefer a Tesla any time over the other cars and will probably soon get one.

MGWT / GWT on the Tesla Model S

    After driving the car I also wanted to see how much the onboard system can actually do. This is running a version of the QT webkit based browser. The complete mgwt showcase was working and you could even think about using a Phonegap approach to build UIs for the car.
    Here is a picture of mgwt running:

    How cool is that?

    Thursday, January 2, 2014

    Profiling GWT applications with v8 and d8

    The v8 JavaScript engine has a command line version called d8 that can be used as a profiler.
    It can help you spot performance problems with your JavaScript in many different ways. If you want to get a good overview of how to profile JavaScript, here is a Google I/O talk on the subject: "Breaking the JavaScript speed limit with v8".
    Unfortunately the d8 profiler was not very useful for GWT applications (or any application that was compiled to JavaScript) in the past, since it highlighted problems in JavaScript with line numbers, which does not make a whole lot of sense for a GWT application. Compiling in pretty mode was no option either, since different code layout will lead to different optimizations in v8 (Currently v8 backs our of optimizing a function if it is too large, also counting comments). And of course you want to profile the same code that will be run by your users.

    This is why we added source maps support to the v8 profiling tools. Using a special GWT linker you can now profile your GWT application in d8 and get back Java line numbers. This is one of the things that we did to help the our colleagues to make Google Sheets as fast as possible.

    Here is how you can profile your GWT application:

    Build v8 locally

    Build your version of v8 using these instructions. After that make sure that d8 (most likely under out/native) and the tickprocessor (tools/mac-tick-processor or tools/linux-tick-processor or tools/windows-tick-processor.bat)  are available in your path.

    Create an entrypoint that runs your performance critical code

    Create a new GWT module with an EntryPoint that calls your performance critical code. In your gwt.xml file you need to add the linker, set the user agent and enable source maps:

    <define-linker name="d8" class=""/>
    <add-linker name="d8" />
    <set-property name="user.agent" value="safari" />
    <set-property name="compiler.useSourceMaps" value="true"/>

    Compile your GWT app

    Now you can just invoke the GWT compiler for your module. It will produce three files that you should move into one directory for your profile:
    • selection script: .nocache.js
    • actual program: .js
    • sourcemap: (located in WEB-INF/deploy//symbolmaps/_sourceMap0.json)

    Run the profiler

    This blog post does not cover all the details on how to use d8, this is much better covered by the v8 team, but most of the times for a GWT app you want to run:

    d8 -prof <modulename>.js

    (You want to make sure that all files are in the same directory and that you are running d8 from that directory)
    This will create a file called v8.log that contains all the information from that profile run. Now we will use the tick processor to analyze this file, but we also need to pass it the source map, so that it can give us Java line numbers:

    linux-tick-processor --sourceMap=<path to sourcemap> v8.log

    This will output a complete profile of your JavaScript. It will show you how much time you spend executing JavaScript (and which functions / Java methods), executing C++ or in library code. It also contains a drill down view of your profile.

    Sum up

    With the changes we made to v8 and GWT you can now use the great v8 toolchain to spot performance problems in your GWT applications. These tools will also allow us to improve the way the GWT compiler translates code in order to make it run faster as well as improving the standard libraries that come with GWT.  You can look forward to your GWT applications running faster in the future.