Need a CLA signed and a patch submitted (http://dojotoolkit.org/cla and http://trac.dojotoolkit.org guest/guest), make sure you indicate in the ticket how you signed and submitted the CLA so I can look at the patch.

I signed and submitted (via fax) a CLA on 13 Jun 2006 when I submitted a minor change. I will open a ticket in trac.

...the bug fix for base64, right? I thought your handle was ringing a bell.

Please file that ticket against me (ttrenka), thanks.

Yes, I think it was a small correction to the Base64 encoding. The ticket number is #5791. I realise that my code is not totally inline with dojo standards. Let me know if this is a problem and I'll see what I can do when I have some spare time.

...spend part of last night doing some profiling and using your add and xor functions; god, what an idiot I was with those two. The perf has increased dramatically (though it's still pretty slow, all things considered); I plan on doing a little more in the next couple of days, and see if I can't get it any faster than that.

If I remember correctly the biggest single impact I got was from inlining the calls to add and xor in $.

From a local test on my machine (MacBookPro 2.4) I can encrypt and decrypt a short message in around 0.26 seconds. Encrypting and decrypting an approx 5,000 char message is taking just less than 0.7 seconds. Both with Safari. Firefox is a little quicker 0.2 secs and 0.45 secs respectively.

(Until it recently failed, I was using a iBook G3 900: it was taking over 0.5 second for the short messages).

Let me know if you think I can help.

Using the Firebug profiler, I spend a good portion of time figuring out which methods/functions were taking the most time, and once I was able to eliminate the split function (based on your code) things did speed up dramatically. I also inlined both the add and the xor in $ (a little more aggressively than you did), which helped a little but not a huge amount.

I'm looking at the idea of inlining those two methods in eb and db right now, which is the current bottleneck. I was also able to shave a few milliseconds off the time by rewriting part of the init function using dojo.map, and also making some of the conversion methods a little more efficient. You can take a look at the test if you want:

http://archive.dojotoolkit.org/nightly/checkout/util/doh/runner.html?tes...

...I included time wrappers around the three basic ops, so you can get a better sense of the amount of time being taken. On Saf 3 (MBP 2.4GHz Core 2 Duo, 4GB RAM), I'm getting an average of 102ms on the encrypt test, 110ms on the decrypt, and about 208ms on the encrypt/decrypt combo. Not nearly as efficient as, say, MD5 or the other crypto algorithms but definitely workable for some things (previously that last test was running an average of 1.5 seconds, so I'd say it's a major improvement).

If you have other suggestions, my lines are always open :)

My brand new MacBook died on me .... luckily early enough to get a replacement. Since then I've been very busy with work.

Your latest code looks good. I profiled the tests with Firebug. It would seem the only worthwhile optimisation would be in eb and there seems little that could be done except inline $ and/or XOR. It would make the code difficult to manage. Probably not worth it for the small gain.

I'll get back to you if I come up with a brainwave.

Was thinking the same thing, and I'm not too sure I want to do something like that; the code is already a little bloated as it is. Playing with a few other ideas about performance, which may lead to entirely different approaches (not in the implementation itself, but where that implementation is actually run).

Sorry to hear about your MacBook, hope it's ok now :)

My replacement MacBook is good.