1
frankblack
XOOPS coding standards the wrong way? OR the benefits of old fashioned coding
  • 2009/12/21 17:18

  • frankblack

  • Just can't stay away

  • Posts: 830

  • Since: 2005/6/13


Sounds provoking and yes it should be! First of all: with this thread I don't want belittle any other coder. This just should a matter to be discussed. So if I annoy anyone with this: SORRY!

My intention for writing this this afternoon was a good one. I just wanted to lift my module on a higher/better level of coding and started roaming around for some state-of-the-art modules. Installed it, looked at the code and was - first of all impressed. So this is top-notch coding I thought and was curious how the modules where behaving in matters of speed performance and consumption of queries.

Testing preferences: all notifications turned off, refreshing templates off, banner off, turned on all permissions. Good module = state-of-the-art module. Bad module = debaser.

My first test scenario: Two empty categories with no files.
Good module:
26 queries
142 included files
XOOPS 1.769 seconds
XOOPS Boot 0.412 seconds
Module init 0.203 seconds
XOOPS output init 0.576 seconds
Module display 0.258 seconds
Page rendering 0.306 seconds
Memory usage: 6675088 bytes

Bad module:
20 queries
93 included files
XOOPS 1.269 seconds
XOOPS Boot 0.299 seconds
Module init 0.049 seconds
XOOPS output init 0.596 seconds
Module display 0.055 seconds
Page rendering 0.256 seconds
Memory usage: 5112800 bytes

Second test scenario: just adding one category:
Good module:
28 queries

Bad module:
21 queries

This means for every added category two queries for the good module?

Third test scenario: submitting a file
Good module:
20 queries
148 files included
XOOPS 1.203 seconds
XOOPS Boot 0.179 seconds
Module init 0.236 seconds
XOOPS output init 0.351 seconds
Module display 0.299 seconds
Page rendering 0.124 seconds

Bad module:
16 queries
136 files included
XOOPS 1.066 seconds
XOOPS Boot 0.251 seconds
Module init 0.239 seconds
XOOPS output init 0.293 seconds
Module display 0.133 seconds
Page rendering 0.135 seconds

For the being inside the categories the bad module was a bit better performing and for the detailed page was better performing, but this was only due to a visual captcha for the bad module.

Test scenario end!

So why should anyone comply to XOOPS module coding standards, when the "old" way is performing better? Security? Can't be. My forms are locked up with token or captchas as well. Compatibility? No, I am using no deprecated functions.

I still can minimize the code lines and increase the speed for my module. Does this also apply for the state-of-the-art modules?

Ony serious answers expected - no flames please. I am just desperately looking for reasons to "move to Blue".

edit: typo in the title. question mark was missing

2
frankblack
Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding
  • 2009/12/21 17:58

  • frankblack

  • Just can't stay away

  • Posts: 830

  • Since: 2005/6/13


Having a closer look at the queries tells astounding things: queries for permissions are scattered all over the place. Queries for protector although not installed. Good module: query for smiles which is never used.

So I "demand" what I thought earlier: permissions are in a bad shape. I am still looking for a solution to get ALL permissions in ONE shot. One of the reasons, why I was "outsourcing" permissions to the preferences.

Next one is the prevention of SELECT * in queries. Maybe it is just a rumour I heard, that the performance is better with SELECT xy, yz in queries. Where applicable of course.

3
trabis
Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding
  • 2009/12/21 18:38

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


Sounds interesting. Where can I download state-of-the-art module?

4
trabis
Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding
  • 2009/12/21 18:42

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


... And XOOPS Boot is before module loading, how are we getting different values?

5
ghia
Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding
  • 2009/12/22 0:20

  • ghia

  • Community Support Member

  • Posts: 4953

  • Since: 2008/7/3 1


Quote:
Next one is the prevention of SELECT * in queries. Maybe it is just a rumour I heard, that the performance is better with SELECT xy, yz in queries. Where applicable of course
Never heard about that.
Maybe there is some gain, when there are 20+ fields in a table and you need only a few. But most XOOPS tables are rather small, so I don't think there is much benefit
Maybe interesting to do once a test and time 1000 requests (or 100 repeated 10 times) eg selecting in the user or a posts table.

Most important is the use of a suitable index.

The permissions has indeed a scaling problem. If you see queries like this, my stommach turns upside down.
Quote:
0.000398 - SELECT * FROM config WHERE (conf_modid = '0' AND conf_catid = '3') ORDER BY conf_order ASC
0.000236 - SELECT DISTINCT gperm_itemid FROM group_permission WHERE gperm_name = 'block_read' AND gperm_modid = 1 AND gperm_groupid IN (1,2)
0.000351 - SELECT b.* FROM newblocks b, block_module_link m WHERE m.block_id=b.bid AND b.isactive=1 AND b.visible=1 AND m.module_id IN (0,-1) AND b.bid IN (127,9,56,38,58,34,41,44,159,45,128,39,42,125,40,43,7,6,3,35,77,75,12,97,96,95,193,
30,1,174,173,54,55,182,181,180,57,179,178,177,176,175,148,71,72,73,74,162,161,160,
158,157,76,78,79,80,156,155,154,153,133,132,131,130,102,101,129,126,115,103,114,
113,112,111,104,110,109,108,107,106,105,100,98,99,53,52,190,189,51,50,49,48,47,46,
37,136,139,138,137,135,134,140,194,36,33,32,31,11,10,8,5,4,196,195,192,191,2)
ORDER BY b.weight, m.block_id
There should be some class that can join the permissions of the groups with the item records, so that in one query all the permitted items for a user can be retrieved.


6
frankblack
Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding
  • 2009/12/22 10:15

  • frankblack

  • Just can't stay away

  • Posts: 830

  • Since: 2005/6/13


A quote from your quote.

Network Performance Tips:

Quote:
1. Minimize traffic by fetching only what you need.
1. Paging/chunked data retrieval to limit
2. Don't use SELECT *
3. Be wary of lots of small quick queries if a longer query can be more efficient
2. Use multi_query if appropriate to reduce round-trips
3. Use stored procedures to avoid bandwidth wastage


Quote:
Sounds interesting. Where can I download state-of-the-art module?


Well, in fact you gave me the advice to look at these series of modules if I remember correctly.

Quote:
And XOOPS Boot is before module loading, how are we getting different values?


I would no worry about that. Test scenario is running locally on XAMPP with other programmes open and working. So this might be a reason?

Maybe if we look at the files included, there could be optimization? I have to look it up again to say nothing false: there were protector queries and files included although not installed. I'll take a closer look...

7
ghia
Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding
  • 2009/12/22 14:05

  • ghia

  • Community Support Member

  • Posts: 4953

  • Since: 2008/7/3 1


Quote:
Network Performance Tips:

1. Minimize traffic by fetching only what you need.
1. Paging/chunked data retrieval to limit
2. Don't use SELECT *
3. Be wary of lots of small quick queries if a longer query can be more efficient

This is true for networks, when the database is on another server as the website. But most XOOPS sites have the database host XOOPS_DB_HOST on localhost, so this does not aplply, or have only limited benefits.

Quote:
Maybe if we look at the files included, there could be optimization? I have to look it up again to say nothing false: there were protector queries and files included although not installed. I'll take a closer look...

Protector Preload?

8
frankblack
Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding
  • 2009/12/22 17:11

  • frankblack

  • Just can't stay away

  • Posts: 830

  • Since: 2005/6/13


Yes, Protector preload. Including 4 files and making one query.

I repacked the firephp-debugger (addons firebug and firephp have to be installed with Firefox) with Smarty debug enabled. I hope I packed it well - get it HERE.

For those who want to log variables on its own, just include this in your file:
require_once XOOPS_ROOT_PATH.'/class/logger/firephp/FirePHPCore/FirePHP.class.php';
$fb FirePHP::getInstance(true);
$fb->registerErrorHandler(false);
$fb->log($whatsmyvalue);


If you want some deep insight to your XOOPS just copy this to the file where you want to get some information about:
function getDefinedVars($varList$excludeList)
  {
      
$temp1 array_values(array_diff(array_keys($varList), $excludeList));
      
$temp2 = array();
      while (list(
$key$value) = each($temp1)) {
          global $
$value;
          
$temp2[$value] = $$value;
      }
      return 
$temp2;
  }

require_once 
XOOPS_ROOT_PATH.'/class/logger/firephp/FirePHPCore/FirePHP.class.php';
$fireme FirePHP::getInstance(true);
 
$excludeList = array('GLOBALS''excludeList''output''xoopsTpl');
 
$varList get_defined_vars();
 
$fireme->log(getDefinedVars($varList$excludeList));


This should be too much of info!

Login

Who's Online

71 user(s) are online (38 user(s) are browsing Support Forums)


Members: 0


Guests: 71


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Jul 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits