either way, who is to say that the ART runtime will be omitted the same way it was in KitKat and Google issues a similar excuse, stupid as it is, to justify it like it did the lack of the runtime even in their Nexus devices? I would bet given that the Note 3 is last generation, that any L update, especially given TouchWiz will pare down on the stock feaures, including the ART runtime. i'd bet it's still stuck in Dalvik. I wish I could enable it as during the stent I had with the S3, it was improving things ten-fold, and I never encountered an app that didn't work with it, nor the symptoms of what would happen if you tried running an app that didn't support it. it was the only time I saw Android perform as smoothly as an iPhone (especially scrolling webpages, no longer choppy)
I'm running a custom ROM on my N3 and it still lacks the option. makes me angry.
There is no Dalvik in Android L, so your question makes no sense. OEMs had the choice to omit ART in KitKat, and some did it to avoid people blaming them for issues that were really the fault of them using an Alpha-level runtime on their devices. The ART in KitKat is not the same as the ART in the Android L Preview which is more a beta, and the one in shipping Android L updates will be a release version that is more finely tuned and developed (i.e. debugged, optimized, etc.).
There is no choice of Dalvik or ART in Android L, so there's no way an OEM like Samsung will ship an update to a device that omits it. The only thing that will be missing in that update, is the Dalvik runtime - completely replaced by ART.
Also, I'm not sure how anyone, anywhere, for whatever reason would insinuate that the Note 3 wouldn't receive Android L, when Samsung has been supporting their flagships for about 2 years since the Galaxy S2...
The Note 3 is likely to receive at least 2 more major updates, Android L and whatever follows it... At the very least.
Also, testing a web browser doesn't really say much for the performance of a platform. Different browsers on Android exhibit different performance levels, on the same device, which is a pretty trivial testament to how worthless such a test is. Just look at the disparity in various web benchmarks between different browsers running on the same exact Android phones. Rendering engines differ. JavaScript engines differ. The engine in Safari is not the same as Chrome or the Samsung Stock browser. Similar, not same.
This is like using a slow graphics library to create a game and then saying Windows sucks for performance, when you could have just used a better graphics library, Lol. The quality of the Rendering Engine says nothing about the platform's general performance. It only speaks to the performance of the Rendering and/or JavaScript engine in that web browser.
However, iOS does have an advantage in that it uses Native Code for most everything. Apps are predominantly native code. The compiler is developed and tuned at the lowest of levels by Apple specifically for their devices and platforms. The frameworks and libraries are very optimized and Apple provides so much API coverage (much more than Google in Android) that developers do not have to "reinvent the wheel" with their own lower-performance code; they just use Apple's APIs. This is often why an app running on different devices can often have a disparity of features across those devices (Camera Apps as a good example).
Performance on iOS is generally almost always faster than on Android, and it's why some Android apps that are also developed on iOS have lower limits than the iOS version (Snapseed can load larger images and crops less when editing larger images, for example). They can handle more while still maintaining a high performance level (and with much less RAM in the device, fewer processing cores, etc.). iOS is extremely optimized - including for power management when you factor in just how TINY those iPhone batteries are, yet they still get battery life comparable to the latest Galaxy S devices with almost twice the battery size.
Google is changing to ART in L, which will increase performance. Using Java was never the *best* choice for a Run Time, but it was the safest choice and the easiest way to get developers onto the platform. It was a compromise they had to make, and they are moving past it in the future. Performance, Memory Management, and Power Management will improve in Android L. Most lag is nothing but stutter, anyways, which isn't the same as lag. A lot of stutter or lag isn't caused by the platform itself, but by the client apps exhibiting the issue.
Chrome on Android has always been pretty terrible. Its saving grace is the Synching of Data to your Google Account and across devices/form factors. If not for that, I don't think anyone would ever use it in lieu of Samsung/HTC/LG's Stock Browser.
Dalvik JITs the code when it's loaded. By the time you're looking at a webpage, Dalvik has already JITed the code from bytecode to machine code, so if you think switching to ART will magically make your web scrolling lag-free, you're setting yourself up for disappointment. If a browser is performing badly, use a different browser is the best course of action.
Chrome loads pages faster than the Samsung browser, but general performance after that is almost always better in the Samsung browser for me. So I keep Chrome disabled.
