5 ms·

Compiled vs interpreted -- is it faster?

ducaale 6y ago
Yup, performance was one of the reasons I decided to port it to Rust. The other reason being that Rust gives you a single binary that is easier to deploy compared to python.
- inshadows 6y ago
  Why do you need more performance from a CLI test tool? I'm honestly curious. It's basically curl (fast) plus simpler and easier interface and pretty printers. For performance in shell scripts you can use curl, and for troubleshooting the IO time dominates anyway.
  - deleted 6y ago
    [deleted]
  - thallada 6y ago
    Why use something slower when an equivalent faster tool is available? There's definitely a noticeable delay on my machine with starting up the python interpreter. Enough that it dominates most actual request times to fast servers. (`http get www.google.com` is ~460ms while `ht get www.google.com` is ~130ms) For a tool I'm constantly using to check APIs I'm developing, I really appreciate snappy commands that give me results that feel instantaneous.
  - pdimitar 6y ago
    It adds up. I once tried to scrape an internal company website / API because we had no PDF exports and wanted to download + export to PDF, with `httpie`. It's an amazing tool but all the startup times compounded pretty badly. I switched to `curl` (which is a bit more pain until I got the full command line right, granted) and the script finished in ~95 minutes as opposed to the ~202 minutes it took with `httpie`. With about 0.5s startup time, it means every 120 requests add a full minute to the final time. And I had to scrape ~125K URLs back then. For a daily casual flow 0.5s startup time might not be much (although people like myself get irritated by that as well but I do recognize it's a minor inconvenience). But when doing mass-scripting such delays can very easily compound to non-trivial time inefficiencies.
    - Scarbutt 6y ago
      To be honest, you approached this problem pretty badly.
      - michaelmrose 6y ago
        This might be a useful comment if you had spent the time to offer thoughts on how it could be better. As it is this comment serves only to gratify your ego whereas advice might help readers. It's worse than adding nothing at all.
      - pdimitar 6y ago
        It was supposed to be a one-off task and I was confident at the time that I can script it quickly. I still scripted it but it took at least half a day. I'll still behind the idea that one has to be able to do one-off tasks without starting a dedicated programming project. It's what scripting languages are meant for. But I did misjudge the speed at which I'll be able to finish the task, that much is true. Ironically I knew exactly what to do from the start but several small and annoying quirks of the shell scripting languages lost me quite a bit of time.
      - killingtime74 6y ago
        Your comment is approached pretty badly.
    - dharmab 6y ago
      For mass-scripting I'd prefer to use a native HTTP library with connection pooling.
      - pdimitar 6y ago
        Sure, I can agree with that somewhat. Still, it was an one-off thing and I didn't want to turn it into a project. Using a for loop, `curl`, `wkhtmltopdf` and `parallel` eventually did the job.
        j0057 6y ago
  - bschwindHN 6y ago
    Because slow startup time is obnoxious for any command-line script. There's no reason to start up an entire scripting virtual machine just to make an HTTP request. No one should be writing serious CLI tools in an interpreted language.
    - inshadows 6y ago
      And yet for decades serious CLI tools are being written in POSIX shell, Bash, Zsh, Awk, Tcl, Perl, Ruby, Python, and no one really complained about speed until now, when hardware is so fast, finally people are starting to notice slow startup times??? C'mon. Python is not Java.
      - bschwindHN 6y ago
        I can definitely tell a difference, and it's irritating. The authors of these tools might not notice or care but I actively avoid them. Magic wormhole is one such example.
- pdimitar 6y ago
  Nice work! As shared down-thread, I really loved and wanted to use `httpie` but the non-trivial amount of startup has put me off. Very happy that you made a Rust alternative because I really don't like `curl` that much -- it requires quite the amount of incantations for non-trivial requests. `ht` and `httpie` definitely improve ergonomics at important places. So, kudos!
adamnemecek 6y ago
How could it not be?
iruoy 6y ago
It definitely is. % hyperfine 'http get EXAMPLE.COM' 'ht get EXAMPLE.COM' -w 10 -r 100 Benchmark #1: http get EXAMPLE.COM Time (mean ± σ): 200.8 ms ± 7.4 ms [User: 178.9 ms, System: 21.1 ms] Range (min … max): 166.5 ms … 221.0 ms 100 runs Benchmark #2: ht get EXAMPLE.COM Time (mean ± σ): 22.7 ms ± 3.2 ms [User: 8.7 ms, System: 5.6 ms] Range (min … max): 15.6 ms … 31.3 ms 100 runs Summary 'ht get EXAMPLE.COM' ran 8.84 ± 1.27 times faster than 'http get EXAMPLE.COM'
- krick 6y ago
  Wow. That's serious difference, I didn't expect that for fetching an url.
  - bpicolo 6y ago
    cpython startup time might account for a good fraction of that
jdright 6y ago
Sorry about asking this, I don't mean to be mean or anything, please don't take offense on this - I'm honestly intrigued. I would like to understand from where a question like this comes, I understand different people have different experiences and backgrounds, but being on this site I would assume this would be kinda obvious. Can you share anything about your experience that can help me understand it?
- staticassertion 6y ago
  I know many people who wouldn't necessarily understand that compiled programs tend to be faster, because it just hasn't come up, or because in their domain it's not really important or even clear. If you've been working primarily with Javascript, for example, or even worse, Typescript, the question of "is this thing compiled or interpreted" is "yes". Compilation becomes a piece of either build tooling, where the artifact isn't a concrete binary, or even an attribute of runtime. It really wouldn't be too hard to imagine a shop built on Javascript and Python, where compilation just doesn't factor into the system in a meaningful way.
  - jdright 6y ago
    Thanks, I see what you mean. I think the TypeScript example makes a great point on the difference of perspectives.
  - unrealhoang 6y ago
    > the question of "is this thing compiled or interpreted" is "yes" Isn’t that answer applied to every programming language?
- Volundr 6y ago
  FWIW as a developer whose worked in both interpreted and compiled languages (but not Python) it's obvious to me that the compiled version will be faster, but it's not obvious that it'd be meaningfully faster. I'd actually expect network latencies to dominate here in many cases. As another commenter mentioned I suspect what's being measured here is the Python startup time rather than performance once things are running. My guess would be a faster to start interpreter (like lua or v8) would rival ht performance, while a slower to start compiled language like the JVM would be as "slow" or slower than httpie.

Yup, performance was one of the reasons I decided to port it to Rust. The other reason being that Rust gives you a single binary that is easier to deploy compared to python.

inshadows 6y ago
Why do you need more performance from a CLI test tool? I'm honestly curious. It's basically curl (fast) plus simpler and easier interface and pretty printers. For performance in shell scripts you can use curl, and for troubleshooting the IO time dominates anyway.
- deleted 6y ago
  [deleted]
- thallada 6y ago
  Why use something slower when an equivalent faster tool is available? There's definitely a noticeable delay on my machine with starting up the python interpreter. Enough that it dominates most actual request times to fast servers. (`http get www.google.com` is ~460ms while `ht get www.google.com` is ~130ms) For a tool I'm constantly using to check APIs I'm developing, I really appreciate snappy commands that give me results that feel instantaneous.
- pdimitar 6y ago
  It adds up. I once tried to scrape an internal company website / API because we had no PDF exports and wanted to download + export to PDF, with `httpie`. It's an amazing tool but all the startup times compounded pretty badly. I switched to `curl` (which is a bit more pain until I got the full command line right, granted) and the script finished in ~95 minutes as opposed to the ~202 minutes it took with `httpie`. With about 0.5s startup time, it means every 120 requests add a full minute to the final time. And I had to scrape ~125K URLs back then. For a daily casual flow 0.5s startup time might not be much (although people like myself get irritated by that as well but I do recognize it's a minor inconvenience). But when doing mass-scripting such delays can very easily compound to non-trivial time inefficiencies.
  - Scarbutt 6y ago
    To be honest, you approached this problem pretty badly.
    - michaelmrose 6y ago
      This might be a useful comment if you had spent the time to offer thoughts on how it could be better. As it is this comment serves only to gratify your ego whereas advice might help readers. It's worse than adding nothing at all.
    - pdimitar 6y ago
      It was supposed to be a one-off task and I was confident at the time that I can script it quickly. I still scripted it but it took at least half a day. I'll still behind the idea that one has to be able to do one-off tasks without starting a dedicated programming project. It's what scripting languages are meant for. But I did misjudge the speed at which I'll be able to finish the task, that much is true. Ironically I knew exactly what to do from the start but several small and annoying quirks of the shell scripting languages lost me quite a bit of time.
    - killingtime74 6y ago
      Your comment is approached pretty badly.
  - dharmab 6y ago
    For mass-scripting I'd prefer to use a native HTTP library with connection pooling.
    - pdimitar 6y ago
      Sure, I can agree with that somewhat. Still, it was an one-off thing and I didn't want to turn it into a project. Using a for loop, `curl`, `wkhtmltopdf` and `parallel` eventually did the job.
      - j0057 6y ago
- bschwindHN 6y ago
  Because slow startup time is obnoxious for any command-line script. There's no reason to start up an entire scripting virtual machine just to make an HTTP request. No one should be writing serious CLI tools in an interpreted language.
  - inshadows 6y ago
    And yet for decades serious CLI tools are being written in POSIX shell, Bash, Zsh, Awk, Tcl, Perl, Ruby, Python, and no one really complained about speed until now, when hardware is so fast, finally people are starting to notice slow startup times??? C'mon. Python is not Java.
    - bschwindHN 6y ago
      I can definitely tell a difference, and it's irritating. The authors of these tools might not notice or care but I actively avoid them. Magic wormhole is one such example.
pdimitar 6y ago
Nice work! As shared down-thread, I really loved and wanted to use `httpie` but the non-trivial amount of startup has put me off. Very happy that you made a Rust alternative because I really don't like `curl` that much -- it requires quite the amount of incantations for non-trivial requests. `ht` and `httpie` definitely improve ergonomics at important places. So, kudos!

adamnemecek 6y ago

How could it not be?

iruoy 6y ago

It definitely is. % hyperfine 'http get EXAMPLE.COM' 'ht get EXAMPLE.COM' -w 10 -r 100 Benchmark #1: http get EXAMPLE.COM Time (mean ± σ): 200.8 ms ± 7.4 ms [User: 178.9 ms, System: 21.1 ms] Range (min … max): 166.5 ms … 221.0 ms 100 runs Benchmark #2: ht get EXAMPLE.COM Time (mean ± σ): 22.7 ms ± 3.2 ms [User: 8.7 ms, System: 5.6 ms] Range (min … max): 15.6 ms … 31.3 ms 100 runs Summary 'ht get EXAMPLE.COM' ran 8.84 ± 1.27 times faster than 'http get EXAMPLE.COM'

krick 6y ago
Wow. That's serious difference, I didn't expect that for fetching an url.
- bpicolo 6y ago
  cpython startup time might account for a good fraction of that

jdright 6y ago

Sorry about asking this, I don't mean to be mean or anything, please don't take offense on this - I'm honestly intrigued. I would like to understand from where a question like this comes, I understand different people have different experiences and backgrounds, but being on this site I would assume this would be kinda obvious. Can you share anything about your experience that can help me understand it?

staticassertion 6y ago
I know many people who wouldn't necessarily understand that compiled programs tend to be faster, because it just hasn't come up, or because in their domain it's not really important or even clear. If you've been working primarily with Javascript, for example, or even worse, Typescript, the question of "is this thing compiled or interpreted" is "yes". Compilation becomes a piece of either build tooling, where the artifact isn't a concrete binary, or even an attribute of runtime. It really wouldn't be too hard to imagine a shop built on Javascript and Python, where compilation just doesn't factor into the system in a meaningful way.
- jdright 6y ago
  Thanks, I see what you mean. I think the TypeScript example makes a great point on the difference of perspectives.
- unrealhoang 6y ago
  > the question of "is this thing compiled or interpreted" is "yes" Isn’t that answer applied to every programming language?
Volundr 6y ago
FWIW as a developer whose worked in both interpreted and compiled languages (but not Python) it's obvious to me that the compiled version will be faster, but it's not obvious that it'd be meaningfully faster. I'd actually expect network latencies to dominate here in many cases. As another commenter mentioned I suspect what's being measured here is the Python startup time rather than performance once things are running. My guess would be a faster to start interpreter (like lua or v8) would rival ht performance, while a slower to start compiled language like the JVM would be as "slow" or slower than httpie.