How are smileys parsed? -- I want to use 1000+ on a big board... bad idea?
 

I tried a similar post @ Vbulletin.com but it hasn't gotten very informative replies yet....

If we are displaying 50 posts per page, will having 1000+ smileys slow Vb down considerably?

I haven't looked at how Vb parses for smileys, but I imagine this could be a bad thing to do depending on how the smilley parsing works.

If tokens trigger replacements then I guess it wouldn't be too bad, but if it is looping over the text looking for 1000+ tokens to replace text with... this would probably not be a good thing.

Does anyone here know how it works offhand?

I doubt it works like this....

But by "tokens triggering replacement"... I mean, you could have a :::3colontrigger for all EXTENDED smileys, extended being, ones that aren't commonly used in normal conversations like :) :P ;) :( :D etc etc... no big deal to have 10 or 20 of those common smileys looped over and replaced (which may be how Vb parses smileys by default?)

But maybe you could get away having tons more smileys on the system if you used a trigger that someone wouldn't normally type... like three colons followed by the smiley name.

When people post a new message, you could put a filter in there that would count (and limit) the number of smiley triggers allowed (including your extended 3 colon trigger smileys) -- to prevent people from attacking the board by making a bunch of repetitive :::3colon tokens with random text.

Make sense?

50 posts per page and 1000 smilies in the DB? Hmmm... I would be interested in the timing numbers with and without smilies enabled.

A couple of points about how it is done:

• Remember that no overhead is required if the post is coming out of the post cache.
• Once per page load the smilies are loaded from a cache, so that looping over the DB entries is not required.
• The work of doing the replacements is a loop that calls preg_replace for every smilie you have defined (50 in your case) -- a simple, but not efficient design.

it should be ok since all parsed posts are placed postparsed table in the db which contains posts already parsed thus not having to run the bbcodeparse_2() function;) the only considerable loading times i may think is the strain of getting 50 posts perpage and the loading times for some users due to their connection speed

<i>all parsed posts are placed postparsed </i>

Just so we do not mislead the inquirer, 'cause I know you know AN, the post cache can only be so large, therefore only the recent N posts will be in the cache.

Good point about 50 posts per page. vB pages are huge even for a small number of posts.

I would advise at least dropping that number to 25 per page, thats is about how far I will set mine. If a user wants to read more they can always go to the next page, no point in adding extra processing time to the page if a user is only intrested in the first few posts.

Less posts per page also means the html sent to the browser will be much smaller, resulting in a quicker display of the page.

In linear mode, this thread, which had 6 posts in it before this reply, was a page of about 54k. Displaying only the first post (1 post/page) is still 37k. The HTML for the single post content is only 693 characters and the HTML for the single postbit is about 4k. This is without the style sheet being inline (sent per page) pe vb.org AdminCP setting.

Folks often focus on server speed, which is very important for a busy site, but for most other sites, concentrating on page size can be just as important.

Bandwidth tips:
- style sheet not inline
- avoid threaded mode
- if you do use threaded, set cache size very small
- set default per page to 10

I wont be using threaded mode... and I'm a portered 2.x style / legacy
postbit kinda guy ;)

These 3.x styles are way too H E A V Y imo. They do look nice, but on long
pages the scrolling time from top to bottom is like 3 times longer than 2.x w/legacy postbit.

I'll feel good knowing I'm saving my members from early tendonitis :P