6 ms·

> PHP pages that take two or three full seconds to render I don't use php personally, but most of my rails apps render full pages in under 100ms. I'd imagine p

by jurre 11y ago

> PHP pages that take two or three full seconds to render I don't use php personally, but most of my rails apps render full pages in under 100ms. I'd imagine php performance to be at least on-par with a full rails app.

jerf 11y ago
I'm thinking Wordpress, or bespoke status pages for internal apps. Of course you can get a PHP page out in under a millisecond if you try hard enough, but it's often not used in that sort of place. (And it often is, but that still doesn't mean it often isn't.) Rails, for that matter, is known for being easy to produce multi-second pages too. Slow languages are slow in practice, too.
- jerf 11y ago
  It actually amazes me that people find the statement that slow languages are actually slow offensive and worthy of downvoting. As I said, it is my experience that simply switching from slow to fast languages even on "IO dominated" workloads has real, visible effects. If you haven't tried it, consider trying it before becoming offended at the idea that your tool may not be appropriate for all use cases. Yes, it can matter when your language is 50 times slower than another.
mtberatwork 11y ago
Once you start seeing hundreds or thousands of requests coming in per second and you see your cpu utilization sky rocket, then the "slowness" of the interpreted languages really comes into full play. Most apps/websites will never achieve this kind of load or scale though.
- Touche 11y ago
  > interpreted languages really comes into full play. There are plenty of non-interpreted languages that don't require GC though. When you pick Rust you are picking manual memory management. Does even Google opt for non-GCed languages for their web servers?
  - steveklabnik 11y ago
    We've been having a debate lately, within Rust, if "manual" is really the right term here. { let x = Box::new(5); // malloc } // free Is this really _manual_? In a sense it is, but it's very different than what most people think about. "Automatic" is kind of a good word, but Objective-C/Swift's "ARC" already covers that, and we don't do refcounting, so that could be misleading too. Maybe "deterministic"?
    - kibwen 11y ago
      Memory management in C is also "deterministic", just forget to ever free. :P
    - DasIch 11y ago
      How about lexical memory management as a nod to dynamic vs. lexical scoping?
      - steveklabnik 11y ago
        That might work for now, but something we're working on for the future is making borrows non-lexical, so....
        kibwen 11y ago
        Borrows may be non-lexical in the future, but deallocation via ownership will always be at the end of a lexical scope. Not only would eager deallocation be bad for performance, it's also a backcompat hazard at this point.
    - gmfawcett 11y ago
      "RAII" seems to cover it nicely, and extends beyond memory management to other resources. Admittedly it's not a very friendly term for non-C++ programmers. What's this non-lexical borrowing idea you mentioned in your other comment? (I can't reply there for some reason.) Is there an RFC for that?

by jurre 11y ago

jerf 11y ago

I'm thinking Wordpress, or bespoke status pages for internal apps. Of course you can get a PHP page out in under a millisecond if you try hard enough, but it's often not used in that sort of place. (And it often is, but that still doesn't mean it often isn't.) Rails, for that matter, is known for being easy to produce multi-second pages too. Slow languages are slow in practice, too.

jerf 11y ago
It actually amazes me that people find the statement that slow languages are actually slow offensive and worthy of downvoting. As I said, it is my experience that simply switching from slow to fast languages even on "IO dominated" workloads has real, visible effects. If you haven't tried it, consider trying it before becoming offended at the idea that your tool may not be appropriate for all use cases. Yes, it can matter when your language is 50 times slower than another.

mtberatwork 11y ago

Once you start seeing hundreds or thousands of requests coming in per second and you see your cpu utilization sky rocket, then the "slowness" of the interpreted languages really comes into full play. Most apps/websites will never achieve this kind of load or scale though.

Touche 11y ago
> interpreted languages really comes into full play. There are plenty of non-interpreted languages that don't require GC though. When you pick Rust you are picking manual memory management. Does even Google opt for non-GCed languages for their web servers?
- steveklabnik 11y ago
  We've been having a debate lately, within Rust, if "manual" is really the right term here. { let x = Box::new(5); // malloc } // free Is this really _manual_? In a sense it is, but it's very different than what most people think about. "Automatic" is kind of a good word, but Objective-C/Swift's "ARC" already covers that, and we don't do refcounting, so that could be misleading too. Maybe "deterministic"?
  - kibwen 11y ago
    Memory management in C is also "deterministic", just forget to ever free. :P
  - DasIch 11y ago
    How about lexical memory management as a nod to dynamic vs. lexical scoping?
    - steveklabnik 11y ago
      That might work for now, but something we're working on for the future is making borrows non-lexical, so....
      - kibwen 11y ago
        Borrows may be non-lexical in the future, but deallocation via ownership will always be at the end of a lexical scope. Not only would eager deallocation be bad for performance, it's also a backcompat hazard at this point.
  - gmfawcett 11y ago
    "RAII" seems to cover it nicely, and extends beyond memory management to other resources. Admittedly it's not a very friendly term for non-C++ programmers. What's this non-lexical borrowing idea you mentioned in your other comment? (I can't reply there for some reason.) Is there an RFC for that?