Is Epiphany faster on Jessie?

[jweob]

I'm using Epiphany in kiosk mode on a Raspberry Pi B+. The Pi has the latest version of Raspbian Wheezy.

Epiphany performs well but I'm hoping to squeeze some more speed out of it. Would upgrading to Raspbian Jessie:

• (a) make no difference?
  (b) speed things up?
  (c) break everything?

[kusti8]

I would say (a) with a hint of (c)

Try kweb as an alternative, although you won't get major speed boost.

[gkreidl]

Epiphany has still to be updated / fixed for Raspbian Jessie. You'll have to wait until it is ready. It won't get any faster, though - how should it?

[Tom_A]

Epiphany has still to be updated / fixed for Raspbian Jessie. You'll have to wait until it is ready. It won't get any faster, though - how should it?

I think that since people have heard that Jessie tends to boot faster (due to using systemd and assuming you can get systemd to work properly) they assume the improvement extends after the boot process and don't understand that once everything is up and running it still runs at about the same speed.

[W. H. Heydt]

The easiest speed boost would be to switch from using a B+ to a Pi2B.

[jweob]

Thanks for the replies, I will stay with Wheezy. I don't have a good explanation for why I thought it might be faster with Jessie other than newer should be better? Or maybe Jessie just sounds faster than Wheezy . I have a bunch of RPi B+ s which is why I'm trying to find a way to use them rather than an RPi2. The loading time for the page doesn't matter because all the interactivity is on one page controlled with javascript. It's more that it is sluggish when reacting to button presses, I will see what I can do to optimise my code instead.

I have tried kweb in the past. I can't remember why I switched to epiphany, I need to revisit it and see what improvement I get.

[Tom_A]

Thanks for the replies, I will stay with Wheezy. I don't have a good explanation for why I thought it might be faster with Jessie other than newer should be better? Or maybe Jessie just sounds faster than Wheezy . I have a bunch of RPi B+ s which is why I'm trying to find a way to use them rather than an RPi2. The loading time for the page doesn't matter because all the interactivity is on one page controlled with javascript. It's more that it is sluggish when reacting to button presses, I will see what I can do to optimise my code instead.

I have tried kweb in the past. I can't remember why I switched to epiphany, I need to revisit it and see what improvement I get.

Are you using any JavaScript frameworks, like jquerry? If so you can improve the speed a bit by not using any frameworks. You might also want to experiment with a USB install and mild over clocking. I think my rpi model b is over clocked to 850 and no over voltage. Also, gpu is at 350. Be careful if you try over clocking.

[gkreidl]

Both my old RPis (B and B+) run rock solid with 1 GHz and 500 MHz for the GPU.
And yes, running the OS from a HDD speeds it up considerably.

[jweob]

I am using a lot of jQuery, I'll try replacing it with plain javascript and see if I can get a performance boost. Thanks for the suggestion!

[Heater]

Yes, everything is faster with Jessie. Us guys in Jessie land are so happy.

At the end of the day I don not believe jQuery is the problem. I hate jQuery with a passion but I'm sure it's quite efficient.

In my experience what is slow is manipulating the DOM itself, no matter how you do it.

Just keep that to a minimum.

[DougieLawson]

At the end of the day I don not believe jQuery is the problem. I hate jQuery with a passion but I'm sure it's quite efficient.

jQuery may be ugly but it is a whole lot easier than writing all of it's functions in your own code. Anything running in a web browser will be dependent on the webkit3 engine as that's where the performance will be gained. If the engine can't run hardware accelerated then the RPi isn't the right platform.

Ephiphany is a buggy mess that is desperately in need of an update and is even worse on Jessie. So your best choice is Günter Kreidl's kweb3 because that's being actively developed.

[jweob]

I'm following the advice to minimise use of jQuery. Based on a test function run in a browser on my desktop computer I think I will get some benefit - using jQuery to select an item by ID seems to be ~5x slower than using javascript

Test Function

Code: Select all

function FaceOff    () {
    console.time('JavaScript');
    for (i = 0; i < 10000; i++) {
        document.getElementById('my-id')
    }
    console.timeEnd('JavaScript');
    console.time('jQuery');
    for (i = 0; i < 10000; i++) {
        $('#my-id')
    }
    console.timeEnd('jQuery')

}

Results:

Code: Select all

FaceOff()
display.js:27 JavaScript: 1.597ms
display.js:32 jQuery: 11.527ms
FaceOff()
display.js:27 JavaScript: 1.264ms
display.js:32 jQuery: 9.974ms
FaceOff()
display.js:27 JavaScript: 2.692ms
display.js:32 jQuery: 17.662ms

[DougieLawson]

What happens if you change your code to

Code: Select all

    function FaceOff    () {
        console.time('JavaScript1');
        for (i = 0; i < 10000; i++) {
            document.getElementById('my-id')
        }
        console.timeEnd('JavaScript1');
        console.time('jQuery1');
        for (i = 0; i < 10000; i++) {
            $('#my-id')
        }
        console.timeEnd('jQuery1')

        console.time('JavaScript2');
        for (i = 0; i < 10000; i++) {
            document.getElementById('my-id')
        }
        console.timeEnd('JavaScript2');
        console.time('jQuery2');
        for (i = 0; i < 10000; i++) {
            $('#my-id')
        }
        console.timeEnd('jQuery2')

    }

so that you don't have the cost of the Javascript engine parsing all of the jQuery code. Does the code tree get cached?

[r3d4]

At the end of the day I don not believe jQuery is the problem. I hate jQuery with a passion but I'm sure it's quite efficient.

jQuery may be ugly but it is a whole lot easier than writing all of it's functions in your own code.

I doubt anyone uses all of JQuerys fuctions , and the most common uses are AFAIR fairly simple just to wrap in a function ...
or you could just not use `shorthand` and use the function names webkit exposes

[Heater]

jQuery is a wonderful thing if you have to support all kind of broken browsers and the difference between browser behaviours. It was no doubt a God send eight years ago. Today browser differences are not so big and people are beginning to say "no" to supporting old IE versions. For them jQuery starts to look a lot less attractive.

Especially that since then a whole bunch new libraries and "frame works" have sprung up that make web apps much easier still. Backbone, Ember, Angular, React etc etc. I have lost count of them.

I finally settled on React.js

https://facebook.github.io/react/

React makes putting together complex GUIs in web apps very easy. It enables and encourages modular creation of modular components. It is not a "framework" that takes over your whole project, you can apply it to just small parts if you like. React is fast. Here is a little experiment with react and svg I put together https://github.com/ZiCog/propanel/tree/master/src

Anyway about that benchmark: Like all such micro-benchmarks it can be very misleading. Sure that element look up may be 5 times faster using vanila JS. But if that is only 10 percent of your codes execution time you are only saving 8% of overall execution time.

Not only that but nothing is done with that returned element. I suspect that if added some code there to modify the element in some way you would find the time spent on DOM manipulation within the browser and re-rendering the page dwarfs the JS execution time.

[jweob]

DougieLawson I don't understand what you mean about the code tree being cached, but the results are quite similar:

Code: Select all

FaceOff()
display.js:27 JavaScript1: 1.294ms
display.js:32 jQuery1: 10.093ms
display.js:38 JavaScript2: 1.325ms
display.js:43 jQuery2: 6.337ms

FaceOff()
display.js:27 JavaScript1: 2.889ms
display.js:32 jQuery1: 16.437ms
display.js:38 JavaScript2: 2.777ms
display.js:43 jQuery2: 5.482ms

FaceOff()
display.js:27 JavaScript1: 1.282ms
display.js:32 jQuery1: 4.165ms
display.js:38 JavaScript2: 1.985ms
display.js:43 jQuery2: 3.977ms

Fair point that this is an artificial benchmark. However, I've now gone through a real part of my code that manipulates the DOM and replaced all jQuery with JavaScript. Using the same method to check times I get >60% reduction. I don't know yet whether once I apply the approach to all my functions I get any improvement running it on the Pi.

[DougieLawson]

There's clearly quite a large overhead in getting jQuery running for the first jQuery function in the code. The second invocation runs quite signifcantly faster. So it does look like you may be able to code around jQuery's overhead.

[Tom_A]

There's clearly quite a large overhead in getting jQuery running for the first jQuery function in the code. The second invocation runs quite signifcantly faster. So it does look like you may be able to code around jQuery's overhead.

JQuery is going to run on the client computer, not the server, but that's extra code in the file that needs to be initially sent. Any performance issues after it downloads will be dependent on the client computer. You can also set client computers to cache content to help with this. I'm sure jQuery is as efficient as any other framework available out there, but when you create a library to handle every possible situation like this, it's not efficient as if you just included the code that you were actually using. jQuery can be very useful, however, if you're looking for a little extra website efficiency, you might see improvements in writing without it.

[Heater]

Tom_A,

Sounds like every one on in this thread is already aware that JQuery runs in the browser not the server.

Yes there is time required for the down load of that library and your JS code. However the timing that has bee done here is measures execution time only. Download is not in the picture and caching will not help.

However, modern JavaScript engines don't just interpret your source code, they use a JIT (Just In time Compiler). That means the first execution of anything may well be slower than subsequent executions. The first time through code is compiled to bits of native executable code. Subsequently it only need run that code, much faster. Typically one would want to run any such benchmark over many iterations and do that more than once.

We could also imagine that the first use of JQuery causes it to create objects and set things up which does not need to repeat subsequently. Thus subsequent runs of a timing test may well be faster.

(Aside: That JIT optimization can be undone during run time. If a data type changes, from number to string say, at run time then the generated native code has to be thrown away and it falls back to slow interpreting)

I do agree. For simple functionality on the page, small amounts of JS, jQuery is an unnecessarily large overhead and learning how to do what you want in vanilla JS is the way to go.

jQuery was no doubt great when browsers were so different and it worked on all of them. I for one don't care if my code no longer works on IE 6 or 8 or whatever old crap.

When you are building a complex web page, "Web App" or "Single Page App" as they like to say now a days, with lots of elements and code and complex interactions between user and server then there are much better alternatives today than jQuery. As I said I have decided to focus on React.js. React makes such designs much simpler by allowing you to modularize components, it's great at doing a lot of complex DOM manipulation and is fast.

[jweob]

I created a more realistic benchmark for my web app which simulated clicking on all the buttons in sequence.

Using native javascript to select DOM elements rather than jQuery reduced the time to complete the benchmark from an average of 7095 ms to 5475 ms (21% less time).

Changing jQuery to javascript on the click handlers didn't make any improvement. I got much more improvement later by optimising my code to touch the DOM as little as possible, but this does show that you can get some significant speed improvement from using native javascript.

[Tom_A]

Changing jQuery to javascript on the click handlers didn't make any improvement. I got much more improvement later by optimising my code to touch the DOM as little as possible, but this does show that you can get some significant speed improvement from using native javascript.

I discussed this with the instructor while taking a Javascript class. I'd imagine that there are some things that run just as fast using jQuery but some things that do have a big performance hit.

[Heater]

How come people often talk about jQuery as if it an alternative language to Javascript?

jQuery is a library. When you use jQuery you are still using Javascript.

There are plenty ways to ensure your use jQuery is not being excessively slow. See optimization tips here for example:

http://code.tutsplus.com/tutorials/10-w ... --net-5551
http://www.jedi.be/blog/2008/10/10/is-y ... rformance/
http://www.artzstudio.com/2009/04/jquer ... nce-rules/

[timrowledge]

However, modern JavaScript engines don't just interpret your source code, they use a JIT (Just In time Compiler). That means the first execution of anything may well be slower than subsequent executions. The first time through code is compiled to bits of native executable code. Subsequently it only need run that code, much faster. Typically one would want to run any such benchmark over many iterations and do that more than once.

It's been quite a while since many interpreters actually read source for each step; most nominally interpreted systems tokenise in some fashion, ranging from trivial keyword tokenisation in many BASICs to full compilation to a sophisticated portable pseudo-code in Smalltalk and most javas etc. The more modern systems (such as Smalltalk since 1984, java since late 90's etc) then translate/compile the pseudo-instructions at runtime for the particular device they're running on. If that takes more than a blink of an eye then it isn't doing the job right. Typically when running a large benchmark suite in Squeak Smalltalk on a Pi the dynamic compilation takes <1% of total time.

We could also imagine that the first use of JQuery causes it to create objects and set things up which does not need to repeat subsequently. Thus subsequent runs of a timing test may well be faster.

That's much more likely to be the startup cost. A common problem is too much initialisation being done when it may not ever be needed. Lazy initialisation is often better for fast startup. It may cost a little more for long running jobs though, so you pays your cycles and makes your choice.

(Aside: That JIT optimization can be undone during run time. If a data type changes, from number to string say, at run time then the generated native code has to be thrown away and it falls back to slow interpreting)

Ooh, now if code is being simply thrown away then you've got the translator wrong. A good system has inline caching, polymorphic inline caching, open caching and can swap from one to the other without throwing ncode away. Really good systems can add class-sensitive runtime optimisation, meta-feedback and probably chocolate.

[Heater]

timrowledge,

Certainly there have been all kinds of methods employed for running interpreted languages, going back to the mother of them all, Lisp.

I would not call the Java an interpreted language system. The Java source code is compiled as much a C++, only rather than compiling directly to real machine code the compiler targets the Java Virtual Machine. Those byte codes are interpreted by the VM. I would say the start up time, from Java source to running code with Java is huge.

Certainly I would expect any bench mark to take significant time to run compared to it's start up time.

However, we are talking Javascript here. I don't have much of an idea what goes on in a modern JS engine only what I have gleaned from the net. I certainly would not suggest the developers of V8 or Spidermonkey are "doing it wrong". In the recent few years the performance of these JS engines has improved dramatically. It is quite incredible that you can now "transpile" C/C++ source into JS and have it run in the browser (or under node.js) at almost the speed of compiled native binaries!

I may not have put it correctly when saying that optimized JITed code is "thrown away". It is certainly true though that if your code does a lot of iterating over an array of elements of the same type it will be optimized very well. But then, if you drop a object of a different type into the array performance drops. The streamlining used for the original array is busted by dropping that new type in there. Similarly it's best if objects don't change their "shape" at run time.

Remember JS is hampered in terms of optimization by being very dynamic language. Types of variables can change at any time. There is no "class" system, objects can change their "shape" at any time and so on. Despite these features the developers of modern JS engines have done an amazing job.

[timrowledge]

Heater, I do hope you didn't get the impression I was attacking you; not my intent at all. I've been doing this dynamic language/Smalltalk thing for 35 years and get a bit antsy anytime the interpreter/compiler/jit subject comes up.
You can probably imagine how it might get annoying to frequently see people claiming 'java invented jit' when it was a couple of old Smalltalk colleagues of mine that did it in 1984!

So, java was originally interpreted in the same way that Smalltalk was, and somewhat similar to BASICs; the source was converted by a compiler to an abstract set of pseudo instructions. At runtime a virtual machine reads those and does whatever is needed. Whether to consider that being interpreted or compiled used to be a topic for huge sprawling debates at the old OOPSLA conferences.

Startup times are an interesting issue for SaaS etc; in the case of java it reads a whole load of code and does lots of startup flim-flammery to generate some objects etc. Smalltalk reads in an entire image file (or snapshot) that is effectively a memory dump of all the objects, and then starts executing where it left off; obviously it has to check if it is running on the same machine or even OS as it was when the image file was saved.
The dynamic translator stuff came later and you know the basics of that, clearly. It has become very sophisticated and as you say some code can run at a surprisingly good speed under javascript - in fact a colleague wrote a Smalltalk vm in javascript that (on a fast pc/mac) can even run the older Scratch image we were using a year or so ago on the Pi. (https://bertfreudenberg.github.io/SqueakJS)

It's all fascinating stuff but I guess we shouldn't be abusing a nominally epiphany related thread.