Forums

Unfortunately no one can be told what FluxBB is - you have to see it for yourself.

You are not logged in.

#1 2019-05-14 04:14:09

JJones
Member
Registered: 2019-04-28
Posts: 18

Has anyone attempted to bench-mark the $lang files?

I just ran a bench-mark on loading both definitions & variables via language file ....

it seems that using this defined variable:

$lang_common['WHATVER_KEY']=>'Whatever Variable';

seems to be requiring more memory usage than:

define(WHATEVER_KEY,'WHATEVER_VARIABLE');

The benchmark shows "almost" 1.7X LESS memory from the current option ....

Under normal circumstances, I probably would not mention anything since my personal threshold of decisions are based on reaching the 2X mark .... BUT... Considering the fact that the language files are divided per page, a translator would need to modify multiple files to reach a fully translatable core ( neglecting the fact that the current core structure is not actually compatible with at least 9 languages ( that i am aware of )...

It is most likely worth another discussion on the core Translation System.

Last edited by JJones (2019-05-14 04:20:09)

Offline

#2 2019-05-14 04:23:22

Visman
Member
From: Siberia
Registered: 2010-07-10
Posts: 1,200
Website

Re: Has anyone attempted to bench-mark the $lang files?

Offline

#3 2019-05-14 06:44:41

JJones
Member
Registered: 2019-04-28
Posts: 18

Re: Has anyone attempted to bench-mark the $lang files?

im well aware of "gettext()" functionality ..... what im not aware of are any specific benefits to a need for it... can you elaborate a bit more on why you believe this suggestion is a "cure all" to a simplistic problem?

Offline

#4 2019-05-14 08:11:02

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,632
Website

Re: Has anyone attempted to bench-mark the $lang files?

2x improvements at the level of microseconds are mostly irrelevant at the level in which these things are used in FluxBB's core. Our runtime is dominated by database queries, so I do not see much value in optimizing these little things at the price of developer ergonomics.


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#5 2019-05-14 10:07:52

JJones
Member
Registered: 2019-04-28
Posts: 18

Re: Has anyone attempted to bench-mark the $lang files?

Franz wrote:

2x improvements at the level of microseconds are mostly irrelevant at the level in which these things are used in FluxBB's core. Our runtime is dominated by database queries, so I do not see much value in optimizing these little things at the price of developer ergonomics.

I repeat, in normal circumstances, I would agree that a few milliseconds are trivial ..... HOWEVER, multiply those millisecond functions based on total Topics/Posts/Signatures/Exec/Exec ... and you now have very slow responding functions that all need to be "updated".... they total 1.3 seconds on 50,000 topics.

As for Database queries ( 9? per page ) .... the simplest solution is a CACHE ... example:

function generate_topic($fid=null)
{
    global $cache, $db;
    if (($arr = $cache->load('TOPIC','FORUM')) === false)
    {
        //$sql = 'SELECT p.poster_id AS has_posted, t.id, t.subject, t.poster, t.posted, t.last_post, t.last_post_id, t.last_poster, t.num_views, t.num_replies, t.closed, t.sticky, t.moved_to FROM '.$db->prefix.'topics AS t LEFT JOIN '.$db->prefix.'posts AS p ON t.id=p.topic_id AND p.poster_id='.$pun_user['id'].' WHERE t.id IN('.implode(',', $topic_ids).') GROUP BY t.id'.($db_type == 'pgsql' ? ', t.subject, t.poster, t.posted, t.last_post, t.last_post_id, t.last_poster, t.num_views, t.num_replies, t.closed, t.sticky, t.moved_to, p.poster_id' : '').' ORDER BY t.sticky DESC, t.'.$sort_by.', t.id DESC';
        $topic_filter = array( // will become global in common
            //'forum_id' => FILTER_VALIDATE_INT, // we null it so that it gets removed from the array but not from the above key
            'id' => FILTER_VALIDATE_INT,
            'poster' => FILTER_SANITIZE_STRING,
            'subject' => FILTER_SANITIZE_STRING,            // could add function to deal with curse words here, but better idea to do it duing injection.
            'posted' => FILTER_VALIDATE_INT,
            'first_post_id' => FILTER_VALIDATE_INT, 
            'last_post' => FILTER_VALIDATE_INT,
            'last_post_id' => FILTER_VALIDATE_INT,
            'last_poster' => FILTER_SANITIZE_STRING, 
            'num_views' => FILTER_VALIDATE_INT, 
            'num_replies' => FILTER_VALIDATE_INT,            
            'sticky' => FILTER_VALIDATE_BOOLEAN,
            'closed' => FILTER_VALIDATE_BOOLEAN,
            'moved_to' => FILTER_SANITIZE_STRING
        );
        $result = $db->query('SELECT forum_id, id, poster, subject, posted, first_post_id, last_post, last_post_id, last_poster, num_views, num_replies, closed, sticky, moved_to FROM '.$db->prefix.'topics') or error('Unable to fetch topic IDs', __FILE__, __LINE__, $db->error());
        $arr=array(0=>array_fill_keys(array('t_num_topics','t_num_posts'), 0));
        while ($row = $result->fetch_assoc() ) 
        {
            //if(!is_array($arr[(int)$row['forum_id']][0])){ $arr[(int)$row['forum_id']][0]=array('t_num_topics'=>0, 't_num_posts'=>0); } //t_num_posts + t_num_replies
            $arr[(int)$row['forum_id']][$row['id']]=filter_var_array($row, $topic_filter);
        }
        $db->free_result($result);
        unset($row,$result, $topic_filter);
        if(count($arr) > 1){ $cache->save('TOPIC', 'FORUM', $arr, ZEND_SAVE_YEAR); }
    }
    return ((is_null($fid))?$arr:(!empty($arr[(int)$fid])?$arr[(int)$fid]:array()));
}

KEEP in mind, that is not MY sql query, that is the query from the latest release, I just took the existing system and wrapped a cache around it and have not gotten to the SQL QUERY cleanups yet.

ZEND_SAVE_YEAR = a JSON encoded array stored for 365 days ( yes that is over-kill, but my interest are based on expansion, and i need outrageous variables to work with to identify core issues that are being compounded into massive loads, and test them against alternative methods  )....

WORSE, I am taking the approach of a singular array structure and "build as you go" .... which basically means, that each time a person clicks on a page, it builds the cache if that content(categories /topics / post )  has never been loaded by anyone else previously ( usually not the case, since an admin would have loaded the page from the admin pages during any system edits ).... ending result = 0 SQL QUERIES ( AT MAX ) for 1 year .... This also includes ADDING posts/topics/blah blah since you can EASILY inject an array inside of an existing array ( ITEM CACHE ) based on the INSERT statement of an SQL query upon submission .... ( ALL of this has 0 to do with improving the language system, but shows that running (9? ) sql queries each page generation is a very simple issue to solve...

I will repeat myself at the risk of coming across as rude, but if people are not willing to "discuss" optimization, the "core" will just keep getting older, and "out of date" and "slower" .... This core is LONG OVER DUE for optimization and massive cleanups.... which is why i am attempting to bring it to the table as a discussion....

As for claiming that a "little thing" here and there are never worth it .... I can simply respond by comparing dirty dishes being piled at the sink. At what point does it become "worth it" to wash the dishes ( when there are no dishes left to use and you have no choice but to wash ALL of them? OR when you have guess viewing your kitchen and coming to the conclusion you are a dirty person? ) ... The analogy is that there are over 30 functions that need attention, i am only looking at them 1 by 1 and attempting to find solutions that provide more functionality ( like the theme limitations which i have already solved (FASTER CORE + ADDITIONAL FUNCTIONALITY) ....

Are you claiming that you only want people to discuss the "issues" in the concept of a massive list? If that is the case, I can do that, but I can nearly grantee that it will only turn into a "blame game" where people from your past will enter the conversation and begin bashing developers ( Which just does not seem to be very productive, and worse won't even do anything but generate more "Forks" from Flux ). As i have stated in my initial post, I am SPECIFICALLY interested in the CORE files, and SPECIFICALLY, PURE PHP base functionality...

AS for WHOM any of this benefits .... I find it insulting to imply that it only benefits the "Developer" ... This is not MY Core, it is YOURS ( are you implying that only I benefit from your core ?) ..... The reality is that ANY part of the core BENEFITS the community ( Capitalism 101 ) ... the Product benefits the people, either directly, or indirectly....

Offline

Board footer

Powered by FluxBB