Tuesday, January 20th, 2009

Passpack ups it game with Gears

Category: Gears

<>blockquote>

Without Gears, it took about 23 seconds to unpack the tags.
Versus just over 1 second for the same operation with Gears.

What is that quote about? Passpack is a long time Gears user, but they have put out a new update that uses Gears in a better way. They use WorkerPools, and it really matters.

Today we’re releasing our first baby-step using the Gears WorkerPool to speed up the encryption/decryption processes.

For now, we’ve optimized the “unpacking tags” process, and the results are impressive. Further optimizations will definitely follow.

How Much Faster Is It?

Passpack makes heavy use of Javascript cryptographic algorithms, so slower machines and certain browsers [cough: Explorer] will see the biggest improvements.

In an entirely unscientific experiment, we timed logging into a Passpack account with 112 tags and about 400 entries.

Web Workers (WorkerPool) are coming to user agents near you!

Related Content:

Posted by Dion Almaer at 6:53 am
4 Comments

+++--
3.1 rating from 10 votes

4 Comments »

Comments feed TrackBack URI

I remember the Gears people saying that Gears for IE used IE’s JavaScript. I begged them to put a faster JS in Gears. Did they do it? Or is it just faster because it doesn’t have to interrupt itself with setTimeout calls?

Comment by Nosredna — January 20, 2009

@Nosredna
Since the performance difference is so huge, I assume that they are not using IE’s engine (someone correct me if I am wrong). In this experiment with Passpack, we have only implemented a few select processes which did not use any setTimeout calls (either before or after gears).

Comment by Sullof — January 20, 2009

@Sullof: Gears does indeed use the browsers’ native JS engine rather than bundling its own. I’ve seen the same thing as Passpack around doing heavy computation on the native browser thread versus a Gears Worker, even though both use the native browser’s underlying JS engine. The difference in performance can be huge; I’m not completely sure why. There is probably some kind of resource competition between the browser’s UI and computationally heavy JavaScript when they are on the same thread that leads to a very long overall slowdown or lockup, like a busy loop in a for() statement. This contention doesn’t happen when the same JS runs on a Gears Worker.

Comment by Brad Neuberg — January 20, 2009

Well, it’s great that it goes so fast, but I wish Gears included a better JavaScript anyhow. I don’t want to think about browser JS issues when I’m programming Gears workers.
.
And idea what percentage of browsers have Gears now?

Comment by Nosredna — January 20, 2009

Leave a comment

You must be logged in to post a comment.