Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
4036
The Pub / Re: Getting ready for an alpha release: WeCSS/Wess improvements
« on December 21st, 2012, 07:40 PM »
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?Quote from Arantor on December 21st, 2012, 07:28 PM About 200-250 last time I checked.Quote '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.
$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?
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.
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.
4037
The Pub / Re: Getting ready for an alpha release: WeCSS/Wess improvements
« on December 21st, 2012, 07:22 PM »
There are hundreds of occurrences of the $user_info array in the code.
I'm thinking that converting those $user_info['is_.....'] entries isn't gonna be a big deal.
However, should I move everything $user_info into we::$user...?
For instance, $user_info['query_see_board']... I'm not sure these kinds of variables translate well into an object, performance Wise.
OTOH, that one's never gonna be called more than a few times per page... Hmm.
I'm starting work on moving loadUserSettings() to self::init_user(), I'll see how it goes. Fingers crossed.......
I'm thinking that converting those $user_info['is_.....'] entries isn't gonna be a big deal.
However, should I move everything $user_info into we::$user...?
For instance, $user_info['query_see_board']... I'm not sure these kinds of variables translate well into an object, performance Wise.
OTOH, that one's never gonna be called more than a few times per page... Hmm.
I'm starting work on moving loadUserSettings() to self::init_user(), I'll see how it goes. Fingers crossed.......
4038
Features / Re: Badges and the displaying thereof
« on December 21st, 2012, 07:20 PM »
Oh... Well, I didn't even know there was already a mod for that...
Anything I write is my own code, not some idea I got somewhere else. Usually :P (There's UltimateProfile which I wanted to totally rip, but never got around to doing that...)
Anything I write is my own code, not some idea I got somewhere else. Usually :P (There's UltimateProfile which I wanted to totally rip, but never got around to doing that...)
4039
Off-topic / Re: How to Apply Thermal Paste the Kentucky Way
« on December 21st, 2012, 07:20 PM »I have many thoughts going on in my head in reply to that, none of which will be split. In hindsight, I should not have posted this vid here, but rather, on a more American-centric board. The joke just doesn't carry well here.
Sometimes it's a neighboring country, like Belgium to France... :whistle:
4040
Features / Re: New revs
« on December 21st, 2012, 06:42 PM »
rev 1802
(42 files, 36kb)
+ Implemented 'we' object, which is the system class containing the equivalent of $context['browser'], and soon $user_info or at least part of it.
(index.php, attic/*, Sphinx/sphinx_config.php, install.php, install.sql, Announce.php, Class-CSS.php, Class-Editor.php, Class-System.php, CoppaForm.php, Dlattach.php, Home.php, Load.php, Aeva-*.php, ManageMedia.php, Subs-Media.php, PersonalMessage.php, Post2.php, Subs-BBC.php, Subs-Cache.php, Subs-Template.php, Welcome.php, TEMPLATES: Admin, Display, GenericMenu, index, Mailer, ManageBoards, ManageMembergroups, ManageNews, ModerationCenter, Packages, PersonalMessage, Post, Profile, Register, Themes, Xml)
(42 files, 36kb)
+ Implemented 'we' object, which is the system class containing the equivalent of $context['browser'], and soon $user_info or at least part of it.
(index.php, attic/*, Sphinx/sphinx_config.php, install.php, install.sql, Announce.php, Class-CSS.php, Class-Editor.php, Class-System.php, CoppaForm.php, Dlattach.php, Home.php, Load.php, Aeva-*.php, ManageMedia.php, Subs-Media.php, PersonalMessage.php, Post2.php, Subs-BBC.php, Subs-Cache.php, Subs-Template.php, Welcome.php, TEMPLATES: Admin, Display, GenericMenu, index, Mailer, ManageBoards, ManageMembergroups, ManageNews, ModerationCenter, Packages, PersonalMessage, Post, Profile, Register, Themes, Xml)
4041
The Pub / Re: Getting ready for an alpha release: WeCSS/Wess improvements
« on December 21st, 2012, 06:26 PM »
I'm still surprised at how slow function overhead can be in PHP... But that's something for PHP to fix, not us. Technically speaking, the same code would run just as fast in JavaScript as without a function call, so I guess that using an Accelerator could improve that side of things in PHP.
Well, I'm still in the process of building my commit list and checking all changes one by one... Very annoying job. At least the code looks cleaner now...
Well, I'm still in the process of building my commit list and checking all changes one by one... Very annoying job. At least the code looks cleaner now...
4042
The Pub / Re: Getting ready for an alpha release: WeCSS/Wess improvements
« on December 21st, 2012, 06:09 PM »
It's is('admin'), not is_admin(), but it's all right to add a helper function... ;)
BTW, I made a few performance tests... 100k calls for each.
(local) $browser['is_ie6'] => 0.02s
we::$browser['is_ie6'] => 0.036s
we::is('ie6') => 0.32s
Oops...
After some heavy micro-optimization on is(), I managed to get it down to 0.2s, it's still about 10 times slower than a local variable test, or 5 times slower than an object variable test, but we're talking about a function that will never, ever be called 100.000 times over the course of a page execution... Even calling it a thousand times will only add 2 milliseconds to the execution time.
Is that okay..?
BTW, I made a few performance tests... 100k calls for each.
(local) $browser['is_ie6'] => 0.02s
we::$browser['is_ie6'] => 0.036s
we::is('ie6') => 0.32s
Oops...
After some heavy micro-optimization on is(), I managed to get it down to 0.2s, it's still about 10 times slower than a local variable test, or 5 times slower than an object variable test, but we're talking about a function that will never, ever be called 100.000 times over the course of a page execution... Even calling it a thousand times will only add 2 milliseconds to the execution time.
Is that okay..?
4043
Features / Re: Badges and the displaying thereof
« on December 20th, 2012, 05:57 PM »
What function?
4044
The Pub / Re: Getting ready for an alpha release: WeCSS/Wess improvements
« on December 20th, 2012, 05:56 PM »
Maybe it doesn't work in strict mode...? I dunno.
Anyway, I've started work on moving $user_info over to the we object.
Basically, use we::$user['is_admin'] or we::is('admin'), depending on your tastes. :)
Anyway, I've started work on moving $user_info over to the we object.
Basically, use we::$user['is_admin'] or we::is('admin'), depending on your tastes. :)
4045
The Pub / Re: Getting ready for an alpha release: WeCSS/Wess improvements
« on December 19th, 2012, 07:10 PM »I was thinking wesys might be better than 'we' for that, but I'm flexible.
I was sure static::$var didn't work, because I'm sure I'd tried it at some point.
4046
The Pub / Re: Getting ready for an alpha release: WeCSS/Wess improvements
« on December 19th, 2012, 02:58 PM »
Starting to wonder if it wouldn't be, hmm, smart to have a generic 'we' (or 'you' :P) object where we'd store contextual information like browser data, RTL mode, $user_info -- we::$user['is_admin'] or we::im('admin'), maybe..?
Would save the need to globalize some stuff like $user_info obviously.
Would save the need to globalize some stuff like $user_info obviously.
4047
The Pub / Re: Getting ready for an alpha release: WeCSS/Wess improvements
« on December 19th, 2012, 08:10 AM »
And in loops, I'm trying to use the variable version anyway.
static::$var is definitely valid on my side... Works quite well.
Class name suggestions please... In all lowercase :)
weua, weu, weage, weuse, webro... (Challenge accepted!) (Oh that was a good episode yesterday....)
static::$var is definitely valid on my side... Works quite well.
Class name suggestions please... In all lowercase :)
weua, weu, weage, weuse, webro... (Challenge accepted!) (Oh that was a good episode yesterday....)
4048
The Pub / Re: Getting ready for an alpha release: WeCSS/Wess improvements
« on December 19th, 2012, 12:02 AM »
Quite a bit = so you'd rather I put weUA::$browser['is_opera'] than weUA::is('opera'), even if I do a quick static cache?
Example:
function is($str)
{
static $is_cache = array();
if (isset($is_cache[$str]))
return $is_cache[$str];
return $is_cache[$str] = self::hasBrowser($str);
}
weUA bothers me a bit... Maybe weua or even 'weu' or weuse would be best... weUA::is() feels strange when typing it. It's a bit... alien.
Other than that, I've finished porting the functions to an object, converted Wess, it's all working I'd say. Some conversion functions in the CSS parser are going to be slower because of the weUA calls, but as they're cached...
Example:
function is($str)
{
static $is_cache = array();
if (isset($is_cache[$str]))
return $is_cache[$str];
return $is_cache[$str] = self::hasBrowser($str);
}
weUA bothers me a bit... Maybe weua or even 'weu' or weuse would be best... weUA::is() feels strange when typing it. It's a bit... alien.
Other than that, I've finished porting the functions to an object, converted Wess, it's all working I'd say. Some conversion functions in the CSS parser are going to be slower because of the weUA calls, but as they're cached...
4049
The Pub / Re: Getting ready for an alpha release: WeCSS/Wess improvements
« on December 18th, 2012, 01:42 PM »
So... I've been wondering about this for the last couple of days.... Still no progress.
In the meantime I've decided I should look into moving $context['browser'] into its own object.
1/ I'm currently using 'weUA' or more likely 'weage' (user AGEnt), dunno if it's for the best beyond the puns (weDge/weAge + we're getting old). I'm known for my unfunny puns so it's probably best to use something else. Don't have to stay in the 'we' + '3 first letters' naming policy, although that would be nice.
2/ Going for a syntax like this: weage::is('ie8'). I could also do weage::$browser['is_ie8'] but it's a bit longer, and I'm not sure calling a function at this point is going to be THAT taxing on overall performance... I've learned my lesson about micro-optimizations really -- they ain't worth it unless you're on a petabyte forum, and even then, you have other worries than saving a few bytes or cycles...
3/ I'm thinking that ::is() could be a good opportunity to actually alias the function to hasBrowser()... i.e., you could do things like, weage::is('ie[8-]') or weage::is('ie || !windows')... Would be a bit slower, though... But I could always do a shortcut at the beginning of the function that would do something like that: if (isset($browser['is_' . $string])) or if (isset($user_info['is_' . $string])) return !empty($user_info['is_' . $string]); ... And voilà, you get pretty much the same functionality as before.
Any opinions on these three suggestions..?
In the meantime I've decided I should look into moving $context['browser'] into its own object.
1/ I'm currently using 'weUA' or more likely 'weage' (user AGEnt), dunno if it's for the best beyond the puns (weDge/weAge + we're getting old). I'm known for my unfunny puns so it's probably best to use something else. Don't have to stay in the 'we' + '3 first letters' naming policy, although that would be nice.
2/ Going for a syntax like this: weage::is('ie8'). I could also do weage::$browser['is_ie8'] but it's a bit longer, and I'm not sure calling a function at this point is going to be THAT taxing on overall performance... I've learned my lesson about micro-optimizations really -- they ain't worth it unless you're on a petabyte forum, and even then, you have other worries than saving a few bytes or cycles...
3/ I'm thinking that ::is() could be a good opportunity to actually alias the function to hasBrowser()... i.e., you could do things like, weage::is('ie[8-]') or weage::is('ie || !windows')... Would be a bit slower, though... But I could always do a shortcut at the beginning of the function that would do something like that: if (isset($browser['is_' . $string])) or if (isset($user_info['is_' . $string])) return !empty($user_info['is_' . $string]); ... And voilà, you get pretty much the same functionality as before.
Any opinions on these three suggestions..?
4050
Features / Re: Plugin revs
« on December 18th, 2012, 12:17 PM »
rev 65 -- Help update, + leftovers I forgot to commit from weeks or months ago...?! Would appreciate reverts if needed :)
* Updating plugins to use generic popup code. (edito_history/EditHistory.php, edito_history/EditHistory.template.php)
* Updating plugins to use generic say() and ask() functions. (mass_upload/attachui.js, calendar/Calendar.template.php, calendar/CalendarPost.php)
! reqWin's return value should be used. (edito_history/History-Topic.php)
! I think a session var should be initialized before it's tested against... (mass_upload/plugin.php)
* Updating plugins to use generic popup code. (edito_history/EditHistory.php, edito_history/EditHistory.template.php)
* Updating plugins to use generic say() and ask() functions. (mass_upload/attachui.js, calendar/Calendar.template.php, calendar/CalendarPost.php)
! reqWin's return value should be used. (edito_history/History-Topic.php)
! I think a session var should be initialized before it's tested against... (mass_upload/plugin.php)