Hacker News new | ask | show | jobs
by zamadatix 2468 days ago
I'd bet a good portion of the difference is between rendering the additional digits as it goes.
2 comments

I didn't note timing numbers, but rendering digits in hex was basically instantaneous, even when doing a million (decimal) digits.

Rendering the digits in decimal was significant delay (like 40 seconds for a million digits). That's why it just shows the hex until the very end, and it shows how long the decimal conversion takes.

You sure you don't mean converting digits to hex instead of rendering? The constant rendering of the hex digits as the work progresses results in a ~3x slowdown for 100k digits in my testing (see my other comment in this tree).
Maybe you're right. I know displaying in hex was way faster than displaying in decimal and seemed fast enough, so I stopped there. I didn't test rendering speed specifically.

Doing a million digits in the console (with no status updates) took about an hour and doing it in that page took just over two hours.

What do you mean, doesn't it do that either way?
Sure but one has 10x more digits than the other so takes a heck of a lot longer to convert and display the string for the same number of iterations.

As a quick test of my theory the majority of the time is being spent trying to display the progress: - Default 100,000 = 58.276 - CSS display: none; = 22.359 - Display when done = 20.057

> Sure but one has 10x more digits than the other so takes a heck of a lot longer to convert and display the string for the same number of iterations.

Hm, I was comparing the same number of digits displayed on screen though. One takes 2s to compute and display 10k digits of information on screen, one takes 30s to compute and display 10k digits of information on screen. same number of digits. At least according to the "progress" output that reads "Digits done".

I may be confused. But you have looked at the demo, right?

> I may be confused. But you have looked at the demo, right?

I have run the demo multiple times, how else would I have generated the time it took for me to run it in the comment above :).

> Hm, I was comparing the same number of digits displayed on screen though. One takes 2s to compute and display 10k digits of information on screen, one takes 30s to compute and display 10k digits of information on screen. same number of digits. At least according to the "progress" output that reads "Digits done".

"Digits done" is the number of correct digits, not the number of displayed digits. It's possible your screen area is too small to notice the difference.

Here is an in progress shot of 10k at 2088 "Digits done" https://i.imgur.com/Fbuw2sc.png

Here is an in progress shot of 100k at 1849 "Digits done" https://i.imgur.com/O1gTogQ.png

As you can see "Digits done" ~= "Digits displayed" in this demo by any means. It simply represents the number of digits that will no longer change as the calculation continues, it is still displaying all the digits every update regardless if they are "done" or not which is where the inefficiencies in rendering come in (and based on the above benchmarks outweigh any other inefficiencies with number size substantially).

Aha, I see, thanks!