4 ms·
This is my least favorite part. As soon as your program gets more complicated the amount of repeated parsing, compilation and setup you need to do for every req
by anarazel 10y ago
This is my least favorite part. As soon as your program gets more complicated the amount of repeated parsing, compilation and setup you need to do for every request causes massive speed and structural issues.
- leeoniya 10y ago> the amount of repeated parsing Which should be near 0 if you can be bothered to enable OPcache in php.ini. Not only parsing/disk reading but also bytecode generation are bypassed.
- anarazel 10y agoSure. But that doesn't really address the problem, just makes it smaller. You still need to reinstantiate a lot of runtime state.
- leeoniya 10y agoI can't tell you how much more "runtime state" exists in PHP than in say Java. In both cases you need to initialize some sort of security-aware context. Once you've eliminated parsing, disk i/o and compilation phases. You should be on pretty even ground of bytecode vs bytecode. Java has a Hotspot JIT, so it will probably win there. I think a JIT is coming to PHP as well since the architectural rework that went into PHP7.
- bpicolo 10y agoThere's more too it than that though, yeah? Say you use a service that uses oauth2 authentication. You need to do a request to pull in a oauth token. If you lose all state between requests, you waste time re-fetching tokens. In PHP, persisting this sort of thing between requests becomes a painful task instead of a triviality
- Klathmon 10y agoBut in most languages http requests should be stateless. Even in node or Java you should be hitting the db to pull that info anyway, as sharing the last info in the process leads to scaling issues as well as big problems if the application crashes. The alternative is crazy sharding systems which are becoming more and more difficult as devices are less and less "static"
- leeoniya 10y agoif you need to persist some data/state between requests, php has a mature memcached extension. it's a fast memory store, but i'm not certain of the security implications since i dont think it has any kind of built-in isolation.
- bpicolo 10y agoSure, but that means I have to either run a memcached instance on every server (which I've actually had to do before just for the sake of PHP) or I have to make network calls for something I shouldn't have to, and then also do serialization/deserialization. That's fine for plenty of things, but certainly isn't optimal for all sorts of stuff. Not to mention, all the other languages out there memcached just as well.
- bkanber 10y agoSession cookies were basically invented for transient statefulness over HTTP.
- bpicolo 10y agoI'm not referring to per-user sorts of things. You can't cache those locally in a sane way in any language. I'm talking about what would usually be memoizable sorts of things.
- bkanber 10y agoThere are memoization libraries for PHP but really it's just another cache implementation. Put it in RAM, put it on disk, put it in memcached or redis, I don't really see too much a difference between $cache->set($key, $value) in PHP vs cache[key] = value in node for instance.
- codedokode 10y agoYou can add a ReactPHP based HTTP server to your app to avoid reinitializing, but you'll have to deal with memory leaks between requests and process management yourself.