Wedge

There aren't that many is_ entries.

query_see_board and all its friends are actually only really used in loadUserSettings and possibly loadPermissions - once they're defined, they're registered to the wesql class and that's pretty much it.

Interesting...
$user_info =& we::$user;

Doing the 1M tests on $user_info['id'] is then faster than doing them on we::$user['id'], meaning that the array's location is not what kills performance, instead PHP is wasting time parsing "we" per se on every call... Really strange. I can only confirm that it doesn't call getInstance() or whatever crap... It's just wasting time on that.
Any solution...? I guess not?About 200-250 last time I checked.'kay then.

I'm torn between keeping $user_info for compatibility (and not having to bother with performance here and there), or getting rid of it for good.

Don't worry about compatibility. This is strictly about cleanliness vs performance, and cleanliness is better IMO so if you're feeling up for it, get rid of it for good.

Yes, calling a static function is not cheap but I don't believe it's significantly slower than calling a normal function.

Well, it's not a function here, it's a static variable, but we get to know exactly the overhead: about 70%... Not that it matters much, again. I'm just worried over nothing much....

I tend to think of everything as functions one way or another ;)

I made a site-wide search & replace for $user_info['is_...'] to be replaced with we:is('...'), and I've found a lot of issues... Most notably plenty of lines where $user_info['is...'] is being written rather than read... So I've been replacing them with we::$user['is...'] instead.
Makes me wonder if it's okay mixing we::$user['is..'] data with we::is() in our source code... I mean, people may start wondering why there are two ways of doing this...

Then again, SMF has $context['user'] which has always eluded me :lol:

Well, $context['user'] is basically a link to $user_info,

Most of the time that we::$user is set anywhere, that would usually imply the we object should be doing that itself rather than something outside setting it.

I guess $context['user'] was added as a convenience for functions that already global $context and forget/don't want to global $user_info... It'll soon be gone, now that the global thingy can go.

I still have something like 1000 occurrences of $user_info to remove... All of the remaining ones are 'simply' $user_info to we::$user replacements, so we're in the area where it takes about twice the time it used to. Should I assume it's going to be okay using these even inside a loop...? I really don't want to spend another 6-7 hours checking each one individually just in case a $user_info variable is used in a heavy loop with 1000+ executions... (Implying we really lose a few milliseconds compared to before.)

It's probably going to be OK - and we can always do profiling later on to figure out where the issues are if need be.

Yeah, I guess...

Hey I caught you posting your commit to another board and then merging it before I had time to do it eheh ;)

Also, while we're at it... Maybe we should also move $user_settings into we::$settings..? (Or something with another name, in case it's confusing.)

I've been doing that for ages.Well, I've thought before about removing that entirely, but it serves an interesting use that loadMemberData doesn't; it allows for putting any columns or values into the members table and retrieving it for the current user essentially for free. I would encourage it to be part of the we object somewhere, we::$settings maybe, but don't forget that we also need to contend with $options which is also user-centric.

I'd probably find another name for it, but not sure what.

Hmm... Yeah, we can always have it as we::$options, too...

I'd actually suggest putting them all into we, and then applying "$options =& we::$options" (or we::$opt) definitions just like I did for $user_info before removing it. Then we can keep it that way and not bother about convert everything if we don't feel like it.
I'm just saying that because I did the entire conversion for $user_info and it killed me. I didn't expect it to be so much work, I'm actually proof-reading my commit for the second time, and am only halfway through it (it's a 350KB diff patch)... I don't know why, but I'm pretty sure I made a mistake somewhere. Hence the double proof-reading...Dunno either.

Also, regarding your latest commit...
- I didn't change loadUserSettings() because the name spoke for itself, but I did consider doing what you did, so if you like it better that way, it's just fine with me. :)
- Forgot about the static keyword in we::analyze, indeed. It did work without it, though... But maybe it was just an oversight and it actually didn't work but didn't tell me. Dunno.
- I'm not sure about the 'public' keyword additions though... If you'll have a look at the wetem object, all public functions are declared without 'public'. Also, in wess, most public functions don't have the public keyword either. There are a few with it, but that's probably a copy-paste gone wrong ahah. Anyway, if you don't specify 'private' or 'protected', it's 'public' by default, and I tend to prefer shorter code because PHP parses it faster. I'd rather we don't use that keyword, then. Do you have any argument in favor of using it..?

If you don't declare the scope, they're automatically public anyway. I just made it explicit rather than implicit. I'm not sure PHP does parse it faster - it's actually historical hangover from PHP 4 when OO didn't have scoping. Aside from that, it's simply good practice.

As far as $options = & we::$opt or whatever, that's fine, but the goal should be eventually to remove it. Global variables are not actually that clever.