4 ms·

Because it's already fast enough for most of us ? Anecdote, but I've had my share of slow things in Javascript that are not slow in Python. Try to generate a SH

Because it's already fast enough for most of us ? Anecdote, but I've had my share of slow things in Javascript that are not slow in Python. Try to generate a SHA256 checksum for a big file in the browser... Good to see progress anyways.

jampekka 3y ago
Python's SHA256 is written in C. And I'd quess Web Crypto API for JS is in the same ballbark. SHA256 in pure Python would be unusably slow. In Javascript it would be at least usably slow. Javascript is fast. Browsers are fast.
- Scarblac 3y ago
  The point of Python is quickly integrating a very wide range of fast libraries written in other languages though, you can't ignore that performance just because it's not written in Python.
- JodieBenitez 3y ago
  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.
  - 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.

jampekka 3y ago

Python's SHA256 is written in C. And I'd quess Web Crypto API for JS is in the same ballbark. SHA256 in pure Python would be unusably slow. In Javascript it would be at least usably slow. Javascript is fast. Browsers are fast.

Scarblac 3y ago
The point of Python is quickly integrating a very wide range of fast libraries written in other languages though, you can't ignore that performance just because it's not written in Python.
JodieBenitez 3y ago
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.
- 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.