4 ms·

Have you tried to generate a SHA256 checksum for a file in the browser, no matter what crypto lib or api is available to you ? Have you tried to generate it usi

Have you tried to generate a SHA256 checksum for a file in the browser, no matter what crypto lib or api is available to you ? Have you tried to generate it using Python standard lib ? I did, and doing it in the browser was so bad that it was unusable. I suspect that it's not the crypto that's slow but the file reading. But anyway... > SHA256 in pure Python would be unusably slow None would do that because: > Python's SHA256 is written in C Hence why comparing "pure python" to "pure javascript" is mostly irrelevant for most day to day tasks, like most benchmarks. > Javascript is fast. Browsers are fast. Well, no they were not for my use case. Browsers are really slow at generating file checksums.

adastra22 3y ago
The Pytthon standard lib calls out to hand optimized assembly language versions of the crypto algos. It is of no relevance to a JIT-vs-interpreted debate.
- masklinn 3y ago
  It absolutely is relevant to the "python is slow reee" nonsense tho, which is the subject. Python-the-language being slow is not relevant for a lot of the users, because even if they don't know they use Python mostly as a convenient interface to huge piles of native code which does the actual work. And as noted upthread that's a significant part of the uptake of Python in scientific fields, and why pypy despite the heroic work that's gone into it is often a non-entity.
  - jampekka 3y ago
    Python is slow, reee. This is a major problem in scientific fields. Currently there are sort of "two tiers" of scientific programmers: ones who write the fast binary libraries and ones that use these from Python (until they encounter e.g. having to loop and they are SOL). This is known as the two language problem. It arises from Python being slow to run and compiled languages being bad to write. Julia tries to solve this (but fails due to implementation details). Numba etc try to hack around it. Pypy is sadly vaporware. The failure from the beginning was not supporting most popular (scientific) Python libraries. It nowadays kind of does, but is brittle and often hard to set up. And anyway Pypy is not very fast compared to e.g. V8 or SpiderMonkey. Reee.
    - pas 3y ago
      The major problem in scientific fields is not this, but the amount of incompetence and the race-to-the-bottom environment which enables it. Grant organizations don't demand rigor and efficiency, they demand shiny papers. And that's what we get. With god awful code and very questionable scientific value.
      - jampekka 3y ago
        There are such issues, but I don't think they are a very direct cause of the two language problem. And even these issues are part of the greater problem of late stage capitalism that in general produces god awful stuff with questionable value. E.g. vast majority of industry code is such.
    - JodieBenitez 3y ago
      > Julia tries to solve this (but fails due to implementation details) Care to list some of those details ? (I have zero knowledge in Julia)
      - jampekka 3y ago
        This is quite a good intro: https://viralinstruction.com/posts/badjulia/ https://viralinstruction.com/posts/badjulia/
        affinepplan 3y ago
        fyi: the author of that post is a current Julia user and intended the post as counterpoint to their normally enthusiastic endorsements. so while it is a good intro to some of the shortfalls of the language, I'm not sure the author would agree that Julia has "failed" due to these details
        jampekka 3y ago
        Yes, but it's a good list of the major problems, and laudable for a self-professed "stan" to be upfront about them. It's my assesment that the problems listed in there are a cause why Julia will not take off and we're largely stuck with Python for the foreseeable future.
  - adastra22 3y ago
    There is pleeeenty of mission critical stuff written in Python, for which interpreter speed is a primary concern. This has been true for decades. Maybe not in your industry, but there are other Python users.
frankjr 3y ago
Just for giggles I tried this and I'm getting ~200ms when reading and hashing 50MB file in the browser (Chromium based) vs ~120ms using Python 3.11.6. https://jsfiddle.net/yebdnz6x/ https://jsfiddle.net/yebdnz6x/
- JodieBenitez 3y ago
  Not so bad compared to what I tried a few years ago. Might finally be usable for us...
  - jampekka 3y ago
    All major browsers have supported it for over eight years. Maybe the problem was between the seat and the keyboard? https://caniuse.com/mdn-api_crypto_subtle https://caniuse.com/mdn-api_crypto_subtle
    - JodieBenitez 3y ago
      Maybe 8 years is not much in a career ? Maybe we had to support one of those browsers that did not support it ? Maybe your snarky comment is out of place ? And even to this day it's still significantly slower than Python stdlib according to the tester. So much for "why python not as fast as js, python is slow, blah blah blah".
- ptx 3y ago
  I thought that perhaps the difference could be due to the JavaScript version having to first read the entire file before getting started on hashing it , whereas the Python does it incrementally (which the browser API doesn't support [0]). But changing the Python version to work like the JavaScript version doesn't make a big difference: 30 vs 35 ms (with a ~50 MB file) on my machine. The slowest part in the JavaScript version seems to be reading the file, accounting for 70–80% of the runtime in both Firefox and Chromium. [0] https://github.com/w3c/webcrypto/issues/73 https://github.com/w3c/webcrypto/issues/73
lambda_garden 3y ago
> Have you tried to generate a SHA256 checksum for a file in the browser Have you tried to do this in Python? A Node comparison would be more appropriate.

adastra22 3y ago

The Pytthon standard lib calls out to hand optimized assembly language versions of the crypto algos. It is of no relevance to a JIT-vs-interpreted debate.

masklinn 3y ago
It absolutely is relevant to the "python is slow reee" nonsense tho, which is the subject. Python-the-language being slow is not relevant for a lot of the users, because even if they don't know they use Python mostly as a convenient interface to huge piles of native code which does the actual work. And as noted upthread that's a significant part of the uptake of Python in scientific fields, and why pypy despite the heroic work that's gone into it is often a non-entity.
- jampekka 3y ago
  Python is slow, reee. This is a major problem in scientific fields. Currently there are sort of "two tiers" of scientific programmers: ones who write the fast binary libraries and ones that use these from Python (until they encounter e.g. having to loop and they are SOL). This is known as the two language problem. It arises from Python being slow to run and compiled languages being bad to write. Julia tries to solve this (but fails due to implementation details). Numba etc try to hack around it. Pypy is sadly vaporware. The failure from the beginning was not supporting most popular (scientific) Python libraries. It nowadays kind of does, but is brittle and often hard to set up. And anyway Pypy is not very fast compared to e.g. V8 or SpiderMonkey. Reee.
  - pas 3y ago
    The major problem in scientific fields is not this, but the amount of incompetence and the race-to-the-bottom environment which enables it. Grant organizations don't demand rigor and efficiency, they demand shiny papers. And that's what we get. With god awful code and very questionable scientific value.
    - jampekka 3y ago
      There are such issues, but I don't think they are a very direct cause of the two language problem. And even these issues are part of the greater problem of late stage capitalism that in general produces god awful stuff with questionable value. E.g. vast majority of industry code is such.
  - JodieBenitez 3y ago
    > Julia tries to solve this (but fails due to implementation details) Care to list some of those details ? (I have zero knowledge in Julia)
    - jampekka 3y ago
      This is quite a good intro: https://viralinstruction.com/posts/badjulia/ https://viralinstruction.com/posts/badjulia/
      - affinepplan 3y ago
        fyi: the author of that post is a current Julia user and intended the post as counterpoint to their normally enthusiastic endorsements. so while it is a good intro to some of the shortfalls of the language, I'm not sure the author would agree that Julia has "failed" due to these details
        jampekka 3y ago
        Yes, but it's a good list of the major problems, and laudable for a self-professed "stan" to be upfront about them. It's my assesment that the problems listed in there are a cause why Julia will not take off and we're largely stuck with Python for the foreseeable future.
- adastra22 3y ago
  There is pleeeenty of mission critical stuff written in Python, for which interpreter speed is a primary concern. This has been true for decades. Maybe not in your industry, but there are other Python users.

frankjr 3y ago

Just for giggles I tried this and I'm getting ~200ms when reading and hashing 50MB file in the browser (Chromium based) vs ~120ms using Python 3.11.6. https://jsfiddle.net/yebdnz6x/ https://jsfiddle.net/yebdnz6x/

JodieBenitez 3y ago
Not so bad compared to what I tried a few years ago. Might finally be usable for us...
- jampekka 3y ago
  All major browsers have supported it for over eight years. Maybe the problem was between the seat and the keyboard? https://caniuse.com/mdn-api_crypto_subtle https://caniuse.com/mdn-api_crypto_subtle
  - JodieBenitez 3y ago
    Maybe 8 years is not much in a career ? Maybe we had to support one of those browsers that did not support it ? Maybe your snarky comment is out of place ? And even to this day it's still significantly slower than Python stdlib according to the tester. So much for "why python not as fast as js, python is slow, blah blah blah".
ptx 3y ago
I thought that perhaps the difference could be due to the JavaScript version having to first read the entire file before getting started on hashing it , whereas the Python does it incrementally (which the browser API doesn't support [0]). But changing the Python version to work like the JavaScript version doesn't make a big difference: 30 vs 35 ms (with a ~50 MB file) on my machine. The slowest part in the JavaScript version seems to be reading the file, accounting for 70–80% of the runtime in both Firefox and Chromium. [0] https://github.com/w3c/webcrypto/issues/73 https://github.com/w3c/webcrypto/issues/73

lambda_garden 3y ago

> Have you tried to generate a SHA256 checksum for a file in the browser Have you tried to do this in Python? A Node comparison would be more appropriate.