Wedge

I'm not actually bothered by it, it is a link after all ;)

file_exists definitely uses the stat cache, glob I'm not so sure about but I can't see any reason it wouldn't be cached at the OS level. Benchmarking is useful - but benching it on Windows is less meaningful than benching it on a Linux server. Windows will give you the worst-case scenario for things like that.

Well, here's the thing, and it's actually the source of some of the 'SMF 2 is slower than SMF 1' theory. It's also incredibly complicated, but bear with me and hopefully I'll explain how it all works.

SMF 1 has no file cache. Thus no queries get cached to files but it can use proper caches like memcache. That means until such times as you're on a grown up cache, you're swallowing the extra load attached to all the uncached queries.

The difference as compared to SMF 2 is though, when you're starting out, the cache miss frequency will be much higher due to low traffic, so in starting out (and, unsurprisingly, prime shared hosting territory) you're not only not benefitting much from the cache because it expires too quickly for the low traffic, you're also paying the overhead attached to it too.

So at the very earliest stages, you carry out extra work compared to SMF 1, and see little benefit - but as soon as you start getting anywhere serious (and by that I mean you start getting any real volume of traffic), the cache soon starts to kick in and benefit, and I suspect the reality is that you'd be able to run SMF 2 on shared hosting longer than you would for SMF 1 because of the caching taking the edge off the DB, and especially that most hosts target CPU as the prime measure of load and don't focus on I/O, so the cache definitely helps there.

I think the file cache is worth doing. The problems with the cache subsystem as they stand are:
1. It's totally I/O bound. As nend's experiments show, there's little you can do to optimise that. So the speed benefit is finite. There are advantages to using the SQLite system as nend suggested, though.

2. Things are not best using the cache, but that's not systemic to the cache itself; the fact $settings is not cached by things other than the file cache is not the fault of the file cache, it is the fault of the housekeeping that drives all of the caching system. Transferring the cache settings to be in Settings.php means it's possible to cache $settings, something not possible in Wedge currently except through the file cache (which is better than nothing)[1]

3. Clearing the non-file caches is difficult and unreliable. Clearing the file cache or even parts of the file cache is trivial by comparison.


Re the menu, the big problem there is the fact that changing the rest of the layout screws other things up too, which is a big con in my book. I know only too well that resizing the browser or other layout causes a lot of hassle when positioning is important (especially if the size of menu panels is dependent on the layout of the screen!) but to me that seems a deal breaker, especially as the complexity of fixing it by binding to the viewport's resize is going to add a fair bit more code.

1.	I'm still floating on whether this particular measure is ideal or not. It does make it a shade harder to force flush the cache because the time of last settings update is also in the settings table (and there is no safe way to put it anywhere else)

(Which is why I switched to SMF 2 in the first place... and, because it was in private beta, how I got into the SMF community after a couple of years of just using SMF1 and posting on my own forums. Anyway -- the file cache never really helped performance on my old server and moving it to a new server helped. I've always been worried about performance in general, and it shows in Wedge...)Yeah, that would explain a lot... (Although my forum already had 200k+ posts when I tried making the switch.)It's pretty much up to PHP to keep things in memory for other simultaneous sessions, yeah.But again, it's mostly I/O bound... (i.e. whether SQLite can deal with the disk access faster than a pure PHP call is up to the machine and setup, I guess...?)

Relying on SQLite, to me, is a bit like creating temp tables in MySQL that bear the names of the cache keys :) Eh, that could be an idea... :lol:You mean it's not possible without a similar rewrite, right..?Isn't it possible to send a global timeout notice or something to the cache handlers...?