[FirefoxOS] "Generating Keys" is pretty damn slow about webogram HOT 29 CLOSED

Yep, that's really slow. On my hardware it usually takes 2-5 seconds to generate key. Same for iPhone e.g.
How can I reproduce this bug? Should I use emulator or real device with FirefoxOS?

from webogram.

Emulator is as fast as desktop Firefox, so it is not a good way to check real speed.

The good way should be to use a real phone (ZTE Open, Geeksphone Keon, Alcatel One Touch Fire).

So I think it should be more clear that app is not blocked and it is just generating someting in the background. It is said, but maybe in a more visual way.

from webogram.

I currently don't have any of the those devices :(

I have only Samsung Galaxy S 4 with Android and iPhone 5. Do I have any options to test this?

BTW, you can also try opening http://zhukov.github.io/webogram/?debug=1 in browser or enable _debugMode in app.js manually. This will give more detailed debug output.

And do you know what JS engine this device has?

from webogram.

This is a low end device, and is the target device (the one that is on the market). More or less like a Nexus One (yes, One!).

I will try tomorrow about setting the debugMode to see what is slow.

This is running the same engine as Firefox, so Spidermonkey with all the optimizations. I think crypto could be rewritten using emscripten to use ASM.js, which should be a speed benefit.

from webogram.

"Generating Keys" forever in firefox 1.2 :(

from webogram.

I've tested using the Firefox OS Simulator and it takes more than 40s since "PQ factorization start" is displayed on the console.

from webogram.

Weird. I have tested it myself with latest 1.4 simulator (firefox extension): almost 15 seconds.

In my firefox nightly is around 1 second.

I don't know why is this slow. How do you create the keys? Do you use the browser "keygen" or something in the app?

from webogram.

@zhukov I've been able to reproduce this in Firefox for Android.

Also found the bottleneck in PQ Factorization, more specifically in the task executed with the Web Worker.

A quick profile shows that TLSerialization's fetchObject recursive calls are taking most of the processing time.

Regards,

from webogram.

This is happening for me with Firefox 24 on desktop too (I'm stuck in RHEL5 were I work).

from webogram.

@zhukov How could I know if it's using closure library or not? Still couldn't go through «Generation keys» on firefox 1.1 phone

from webogram.

Same for me.. I'm going to debug deeper tomorrow on device. This fix improved the process on desktop and I thought it will definitely solve mobile problems.
But it seems like 1.1 doesn't support remote debugging. So I have to do this with alerts and so.

from webogram.

Maybe this could be helpful. I have this with adb logcat:

This happen after write my phone number:

E/GeckoConsole( 180): Content JS WARN at app://keyboard.gaiamobile.org/js/keyboard.js:754 in modifyLayout: No space key found. No special keys will be added.
E/GeckoConsole(14986): Content JS LOG at app://d6b3d706-bb09-47cc-a597-eecec2ea0672/js/lib/mtproto.js:1203 in mtpSendReqPQ: [41.714] Send req_pq b67d8ffb410665a92b8c8f6bd0809684
E/GeckoConsole(14986): Content JS LOG at app://d6b3d706-bb09-47cc-a597-eecec2ea0672/js/lib/mtproto.js:1220 in anonymous: [42.611] Got ResPQ abc3dd46acce60eba4051b06701c741c 1e1e7a0b0d485099 14101943622620965665
E/GeckoConsole(14986): Content JS LOG at app://d6b3d706-bb09-47cc-a597-eecec2ea0672/js/lib/mtproto.js:1228 in anonymous: [42.617] PQ factorization start

from webogram.

Hm.. how do you get this log? This one is pretty useless but the fact that you managed to get it is interesting.

from webogram.

I don't know if you could get something better, then. But what I do is connect my Firefox 1.1 phone by usb and writ in a terminal:
adb logcat | grep Gecko

from webogram.

I have access to all FXOS devices if you need me to run any tests.

from webogram.

The long time causes the app to fail on 1.1 as 1.1 does not show long-running script warnings but just kills the script and therefor leaves a dead app corpse.

This slow key generation issue it tracked at https://bugzilla.mozilla.org/show_bug.cgi?id=1014649 . We either need to fix the closure Long library or to rewrite the key generation with another library.

from webogram.

I'm seeing key generation taking 20 to 40 seconds on Firefox for Android on a Galaxy SII. That's slow but I think could be dealt with by appropriate UI messaging e.g. "Your keys are being generated, this may take several minutes on slow devices but will only happen once, thank you for your patience." @zhukov am I correct in thinking this only needs to happen once per phone number as long as localStorage persists?

@digitarald Does FxOS 1.1 support web workers? If the calculation is happening in a worker shouldn't it just keep going until it finishes rather than timing out (as it's not blocking the UI thread)?

It would be good to see if the pqPrimeBigInteger implementation takes as long to run as pqPrimeLong in memory constrained environments like the reference FxOS devices (it might not trigger as much garbage collection). I don't have a device to test on right now.

If we can get this to the point of taking a long time (once?) rather than hanging the app then I think we should add soothing UI messages and make improved performance a priority rather than a blocker to release.

from webogram.

@digitarald Does FxOS 1.1 support web workers? If the calculation is happening in a worker shouldn't it just keep going until it finishes rather than timing out (as it's not blocking the UI thread)?

Yes, the test case actually shows off the code running in a web worker: https://github.com/digitarald/webogram-issue-40 . It takes noticeable longer but finishes. I absolutely agree that this can work with the right messaging as it only happens once. It needs to happen on a web worker to not trigger the long running script death.

from webogram.

The code suggests that the key generation should be happening in a worker, as long as window.Worker is truthy for FxOS 1.1 (I don't have a device to check on right now). So I'd expect key generation to be slow but not to kill the app.

I've created pr #320 to make it clear that key generation is slow on some mobile devices.

from webogram.

@jimCresswell I've checked 1.1 with Workers, it's working infinite amount of time. But 1.3 completed in couple minutes which is more or less comfortable.

from webogram.

@zhukov thanks for checking. @digitarald do we know if a long-running worker will kill the app in 1.1?

from webogram.

I've added new issue #351 for implementing new bigint. Hope, that it may help.

from webogram.

It seems like the new library has a maximum perfomance, we can get from Javascript. it still takes around 1-2 minutes on FFOS 1.1, but from now on it should eventually finish.

I've created the separate repo: https://github.com/zhukov/prime-factorization-benchmark with benchmarks. May be it will help somebody in the future.

from webogram.

Great news!

from webogram.

After the new library was merged into master, I was able to check results for the app on device.
So the real-world numbers for my Keon w/FFOS 1.1 are little worse: around 4 minutes from button click till the code sent. This number may double if the user's ip geo location will require to use another Telegram datacenter (because it will require one more key generation).

This number differs from the one from table that much probably because Math.random() takes a lot of extra time. But the difference is obvious. Perhaps, we can replace Math.random() with precalculated values in the future to add some more perfomance.

Anyway, previous version didn't manage to complete at all (for my phone + OS), so I guess, it's a good result.

Guys, you can also share updates here, if you use 1.1.

from webogram.

For the record, this is what other firefox os apps use to generate keys (in this case OTRS keys):

https://github.com/loqui/im/tree/dev/scripts/arlolra

(around 120s on a ZTE Open)

from webogram.

@nukeador that's the same bigint library btw 👍

from webogram.

I've the same problem with Firefox (fennec, and desktop versions)

from webogram.

@DiogoConstantino what is the hardware? Did you try the same in different browser? Safari / Chrome / Opera ? Can you collect debug info from console?

from webogram.