this post was submitted on 30 Oct 2023
989 points (96.1% liked)

Programmer Humor

32343 readers
1182 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] aksdb@feddit.de 4 points 1 year ago (2 children)

For a bit of templating? Yes! What drives response times up is typically the database or some RPC, both of which are out of control of PHP, so I assume these were not factored in (because PHP can't win anything there in a comparison).

[–] naught@sh.itjust.works 4 points 1 year ago (1 children)

Anything under like 100ms load is instant to the user, especially a page load. It's a balancing act of developer experience vs performance. To split hairs over milliseconds seems inconsequential to me. I mean, PHP requires $ before variables! That's the real controversy :p

[–] aksdb@feddit.de 4 points 1 year ago

Anything under like 100ms load is instant to the user, especially a page load.

True, but it accumulates. Every ms I save on templating I can "waste" on I/O, DB, upstream service calls, etc.

[–] jaybone@lemmy.world -1 points 1 year ago (1 children)

If it’s stateless and nothing is kept in memory, can you have a connection pool?

[–] aksdb@feddit.de 0 points 1 year ago

If you run it in old-school CGI mode, no, because each request would spawn a new process. But that's nowhere near state-of-the-art. So typically you would still have a long-running process somewhere that could manage a connection pool. No idea if it does, though. Can't imagine that it wouldn't, however, since PHP would be slaughtered in benchmarks if there was no way to keep connections (or pools) open across requests.