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
5146
The Pub / Re: The Cookie Law (in the UK at least)
« on May 20th, 2012, 06:59 PM »
Splash pages on websites?! Great Scott! Marty, we're back in 1985!!
5147
Features / Re : Rewriting the skin file parser...
« on May 20th, 2012, 06:07 PM »
Tested here...
file_exists method: 0.15 to 0.35ms, average: 0.2ms.
glob method: 0.4 to 0.7ms, average: 0.5ms
It's still twice slower, but still under a millisecond...
What really scared me, though, is that right after I uploaded my file and refreshed, it sent me a benchmark 1.65 SECOND for that code block...! Then I refreshed, and it went under a millisecond.
I don't know what it means, but to me it means only one thing -- glob() is indeed cached by Apache across all page requests :P
Hmm... The current version here is the file_exists one, and I *just* had a 1.15 second benchmark time for it. So I guess it's not limited to glob()... It's just that glob() is a bit slower in every task.
file_exists method: 0.15 to 0.35ms, average: 0.2ms.
glob method: 0.4 to 0.7ms, average: 0.5ms
It's still twice slower, but still under a millisecond...
What really scared me, though, is that right after I uploaded my file and refreshed, it sent me a benchmark 1.65 SECOND for that code block...! Then I refreshed, and it went under a millisecond.
I don't know what it means, but to me it means only one thing -- glob() is indeed cached by Apache across all page requests :P
Posted: May 20th, 2012, 06:03 PM
Hmm... The current version here is the file_exists one, and I *just* had a 1.15 second benchmark time for it. So I guess it's not limited to glob()... It's just that glob() is a bit slower in every task.
5148
Features / Re: Aeme features ideas.
« on May 20th, 2012, 04:38 PM »
Searchable, yes, it's a bonus. Heck it was my main point for going floating actually :P
How about we make the messages table fixed-width, if it's faster? I'm sure we could move non-fixed data to a secondary table :lol:
j/k, although we could use a few minutes of our time to evaluate that ;)
How about we make the messages table fixed-width, if it's faster? I'm sure we could move non-fixed data to a secondary table :lol:
j/k, although we could use a few minutes of our time to evaluate that ;)
5149
Features / Re : Rewriting the skin file parser...
« on May 20th, 2012, 04:26 PM »
Either way I'm sure it's always fast.
And there's always our own caching. :)
And there's always our own caching. :)
5150
Features / Re : Rewriting the skin file parser...
« on May 20th, 2012, 01:09 PM »It's not cached by stat...
http://[url]http://www.php.net/manual/en/function.clearstatcache.php[/url]
There's a list of functions affected -- glob is not among them.
It's a local thing, so it's based on Windows 7 + i7 CPU (quad core, 3+Ghz...) + 8GB Ram, and would probably be slower on a 'regular' server (even if running Linux).
By calling the entire CSS caching, it takes about 0.4ms in the current SVN, and about 0.7ms in the glob() version. That's about 50% slower, and the file searching code itself is probably even twice slower (because the entire function has more code than just the file search...), but still -- it's less than a millisecond. We're talking about web pages that always take at least 120 milliseconds to generate on my PC. It seems to be acceptable -- and if anything, it can be sped up by caching the file list...
I think I'll keep it this way. It still needs some (a lot of?) work to make it work across fallback folders, but other than that, it seems to be working.
Only issue, maybe: I'm using GLOB_BRACE to avoid using multiple glob() calls, but the php.net documentation says that it's not supported everywhere, giving Solaris as an example... I suspect that isn't that big of a deal, but still...
Posted: May 20th, 2012, 12:59 PM
Doing some quick tests between one version and the other...
Old version: 0.4 to 0.7ms (average: 0.5-0.6ms)
New version: 0.5 to 0.8ms (average: 0.7-0.8ms)
So, it's not even 50% slower actually... :^^;:
5151
Features / Re: Aeme features ideas.
« on May 20th, 2012, 10:08 AM »
I don't know, I've just never been a big fan of storing subjects when most of the time they're the same as the topic's...
Heck, I don't remember if Wedge stores the subject if it's the same. I think the Noisen codebase stores an empty subject or just 'Re:' in that case, but I'm not sure.
Heck, I don't remember if Wedge stores the subject if it's the same. I think the Noisen codebase stores an empty subject or just 'Re:' in that case, but I'm not sure.
5152
Features / Re: Aeme features ideas.
« on May 20th, 2012, 09:21 AM »
Re: sorting, I was definitely thinking about adding a poster_time field to the topic table as well, so it'd at least wouldn't require a join just to do the sorting... There aren't that many places where a rewrite is required...?
I didn't think about the last poster time though, sounds like a good idea...
Anyway, the topic table is definitely one of the least polluted in the entire table list. Most of its data is taken from its id_first_msg indeed, but I'm sure we could benefit from moving some of this data into the table.
Heck, I'm sure we could even benefit from moving the subject into the topic... :P Maybe even remove it from the post table but I'm sure some people would kill me for that :lol:
I don't mind using entire boards for an album. I just hope you realize that it'll make the topic table grow way more quickly than if we stored one album per topic :)
I didn't think about the last poster time though, sounds like a good idea...
Anyway, the topic table is definitely one of the least polluted in the entire table list. Most of its data is taken from its id_first_msg indeed, but I'm sure we could benefit from moving some of this data into the table.
Heck, I'm sure we could even benefit from moving the subject into the topic... :P Maybe even remove it from the post table but I'm sure some people would kill me for that :lol:
I don't mind using entire boards for an album. I just hope you realize that it'll make the topic table grow way more quickly than if we stored one album per topic :)
5153
Features / Re: Aeme features ideas.
« on May 19th, 2012, 11:48 PM »
- Ordering by poster_time means adding an extra key, although in the messages table there's already a surprising amount of keys...
- My main concern with converters is that TE isn't around much these days... Hasn't been online in weeks, hasn't posted in a month. I'd rather have media albums converted to floating boards at import time -- if anything, we can always remove the items from around here, or even do the conversion manually...
So, who writes the converter code, eh eh...
- I suppose it's okay doing everything by id if topics can be filtered by board type... In which case they'll always be sorted correctly.
- I don't even know if it's best to have an album = a board, or a gallery = a board... If an album = a board, then an item = a topic. Let's consider that if a topic is sticky or something, it means it's an album topic, not an item topic. If an album = a topic, then we could have it done this way: any replies = album comment, new items are posted as a special post in these topics, and from within the item page, if you comment on the item, it actually posts a reply to the album topic but it's set to have the item's special post as its PARENT internally... See? A threaded discussion. It's harder to manipulate though (moving items around, deleting them...), but I find the idea amusing.
- My main concern with converters is that TE isn't around much these days... Hasn't been online in weeks, hasn't posted in a month. I'd rather have media albums converted to floating boards at import time -- if anything, we can always remove the items from around here, or even do the conversion manually...
So, who writes the converter code, eh eh...
- I suppose it's okay doing everything by id if topics can be filtered by board type... In which case they'll always be sorted correctly.
- I don't even know if it's best to have an album = a board, or a gallery = a board... If an album = a board, then an item = a topic. Let's consider that if a topic is sticky or something, it means it's an album topic, not an item topic. If an album = a topic, then we could have it done this way: any replies = album comment, new items are posted as a special post in these topics, and from within the item page, if you comment on the item, it actually posts a reply to the album topic but it's set to have the item's special post as its PARENT internally... See? A threaded discussion. It's harder to manipulate though (moving items around, deleting them...), but I find the idea amusing.
5154
Features / Re: Aeme features ideas.
« on May 19th, 2012, 11:21 PM »
Any smart suggestions then...?
Of course even with a dual index on I'd_board we can't avoid sorting by time rather than by id. Tbh I really chose this path Brcause I didn't want to bother too much with importing data... But were still gonna have to do it anyway.
Doctor Who night tonight on channel France 14. 5 reruns of seasons 2005 and 2011 and first runs of Genesis of the Daleks, Edge of Destruction and City of Death. Yay!!
Only way to sort by Id is to filter by board type and only show one at a time...
Bump...?
(So, do we add an index on poster_time, maybe...?)
Of course even with a dual index on I'd_board we can't avoid sorting by time rather than by id. Tbh I really chose this path Brcause I didn't want to bother too much with importing data... But were still gonna have to do it anyway.
Doctor Who night tonight on channel France 14. 5 reruns of seasons 2005 and 2011 and first runs of Genesis of the Daleks, Edge of Destruction and City of Death. Yay!!
Posted: May 19th, 2012, 09:09 PM
Only way to sort by Id is to filter by board type and only show one at a time...
Posted: May 19th, 2012, 09:11 PM
Bump...?
(So, do we add an index on poster_time, maybe...?)
5155
Features / Re: Aeme features ideas.
« on May 19th, 2012, 08:37 PM »
Iunderstand your pov but you're probably forgetting about forum imports. We could get away with it by importing all albums and items into the topic table as new items but then we lose the date posted/id relationship. If you sort topics by date you get old items at the top of the list. I had this problem with my blog when I imported it into noisen. I had to fix it by sorting by time instead of id... Meh!
5156
Features / Re: Aeme features ideas.
« on May 19th, 2012, 07:43 PM »
I don't see why it would be harder to extend.
Also, getting rid of auto increment forces us to specify the board type in the URL and do the main index on (id_topic, board_type)... Not sure it'd be very efficient?
Also, getting rid of auto increment forces us to specify the board type in the URL and do the main index on (id_topic, board_type)... Not sure it'd be very efficient?
5157
If you can deal with using a French datacenter (i.e. likely to be very slow for you), and I'm not sure they all accept overseas customers, but I know these are reputable service providers:
http://www.ovh.com/fr/vps/ (about 20€/mo. for 512MB Ram, decent bandwidth...)
http://www.kimsufi.com/ (from the same guys -- dedicated 2GB Ram servers at 15€/mo.)
http://www.kimsufi.com/fr/vks/index.xml (VPS on kimsufi -- 2GB Ram at 15€/mo. just the same...)
http://www.online.net/serveur-dedie/comparatif-serveur-dedie-start-hp.xhtml (Dedibox, mostly at 15€ and 30€, are a geek favourite from the French ISP Free aka Iliad aka Online.)
http://www.ovh.com/fr/vps/ (about 20€/mo. for 512MB Ram, decent bandwidth...)
http://www.kimsufi.com/ (from the same guys -- dedicated 2GB Ram servers at 15€/mo.)
http://www.kimsufi.com/fr/vks/index.xml (VPS on kimsufi -- 2GB Ram at 15€/mo. just the same...)
http://www.online.net/serveur-dedie/comparatif-serveur-dedie-start-hp.xhtml (Dedibox, mostly at 15€ and 30€, are a geek favourite from the French ISP Free aka Iliad aka Online.)
5158
Features / Re: Aeme features ideas.
« on May 19th, 2012, 05:34 PM »
Album comments is one of the features that had been in AeMe's to-do-list for years...
I never got around to implementing them.
One of my goals with floating boards, is to make it relatively easier to implement this kind of thing.
Let's just say that board #355 is of type 'album' (or whatever), internally associated to album #421, and has topic #7234 associated to media item #6212. (We really should add a meta_id field to the topic table where we could store this kind of relationship data...)
So, every time you want to post a general comment in the album #421, that means posting a message in topic #7122 which is in board #355 and has a meta_id of #0, meaning "album comment"...
(It may sound a bit weird, but that's pretty much the only possible way to implement floating boards without breaking the auto-incrementing aspect of topic IDs...)
I'd love opinions on this implementation concept!
A temporary workaround would also be to show in the album homepage a list of the most recent comments for any items within the album. At least, that could be implemented right now... It doesn't solve the "where do I post if I don't want to comment on anything special?" issue, though...
I never got around to implementing them.
One of my goals with floating boards, is to make it relatively easier to implement this kind of thing.
Let's just say that board #355 is of type 'album' (or whatever), internally associated to album #421, and has topic #7234 associated to media item #6212. (We really should add a meta_id field to the topic table where we could store this kind of relationship data...)
So, every time you want to post a general comment in the album #421, that means posting a message in topic #7122 which is in board #355 and has a meta_id of #0, meaning "album comment"...
(It may sound a bit weird, but that's pretty much the only possible way to implement floating boards without breaking the auto-incrementing aspect of topic IDs...)
I'd love opinions on this implementation concept!
A temporary workaround would also be to show in the album homepage a list of the most recent comments for any items within the album. At least, that could be implemented right now... It doesn't solve the "where do I post if I don't want to comment on anything special?" issue, though...
5159
Features / Re: New revs
« on May 19th, 2012, 05:22 PM »
rev 1586
(2 files +1, 5kb)
* As usual, spending hours working on things that will only save a few bytes... That's me. I'll be here all week. Removed weCookie() which was only used once in the entire codebase, and replaced the call with a tighter, optimized regex. Rewrote some .css() calls to save another few bytes (this one is odd, but I tried all permutations, and the more normal ones can take up to 10 more gzipped bytes...) (script.js, attic/Unused-cookie.js)
* Made the poster area background a bit less obvious. I just wanted to tone it down... Sue me. (sections.css)
(2 files +1, 5kb)
* As usual, spending hours working on things that will only save a few bytes... That's me. I'll be here all week. Removed weCookie() which was only used once in the entire codebase, and replaced the call with a tighter, optimized regex. Rewrote some .css() calls to save another few bytes (this one is odd, but I tried all permutations, and the more normal ones can take up to 10 more gzipped bytes...) (script.js, attic/Unused-cookie.js)
* Made the poster area background a bit less obvious. I just wanted to tone it down... Sue me. (sections.css)
5160
Features / Re: gallery from the admin pov
« on May 19th, 2012, 08:20 AM »
Prettier? How so? I just had a look and I find their galleries ugly and unusable... :-/
(And I've pretty much stopped working on AeMe so it's not like I'd be jealous or anything.)
(And I've pretty much stopped working on AeMe so it's not like I'd be jealous or anything.)