Support Forums - XOOPS Web Application System

Subject:* <
Name/Email:* <
Message Icon:* <
Select* <
Message:* <	xx-Small x-Small Small Medium Large x-Large xx-Large Arial Courier Georgia Helvetica Impact Verdana Haettenschweiler Black Blue Brown Green Grey Orange Paper Purple Red White Yellow [quote] frankblack wrote: 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. [b]My first test scenario: Two empty categories with no files.[/b] 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 [b]Second test scenario: just adding one category:[/b] Good module: 28 queries Bad module: 21 queries This means for every added category two queries for the good module? [b]Third test scenario: submitting a file[/b] 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. [b]Test scenario end![/b] 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[/quote] Click the Preview to see the content in action.
Options:* <	Enable Smiley Enable Xoops Code
Confirmation Code* <	9 - 8 = ? Input the result from the expression Maximum attempts you can try: 10
* <

Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding

by frankblack on 2009/12/22 17:11:01

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:

le="color: #000000"><?php 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:

le="color: #000000"><?php 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!

Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding

by ghia on 2009/12/22 14:05:54

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?

Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding

by frankblack on 2009/12/22 10:15:18

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...

Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding

by ghia on 2009/12/22 0:20:10

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.

Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding

by trabis on 2009/12/21 18:42:16

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

Search

Advanced Search

Donat-O-Meter

Stats
Goal:	$15.00
Due Date:	Jul 31
Gross Amount:	$0.00
Net Balance:	$0.00
Left to go:	$15.00

Latest GitHub Commits

{{ record.sha.slice(0, 7) }} - {{ record.commit.message | truncate }}

{{ record.commit.author.name }} {{ record.commit.author.date | formatDate }}

Search

Recent Posts

Re: XOOPS 2.7.1-RC1 Released for Testing

Re: XOOPS 2.7.1-RC1 Released for Testing

Coming soon: fully rewritten PEDIGREE

XOOPS Cocktails available for testing

Quotes module available for testing

mTools available for testing

XOOPS 2.7.1-RC1 Released for Testing

Re: New XOOPS 2.7.0 Documentation in development

New XOOPS 2.7.0 Documentation in development

Re: XOOPS 2.7.0-RC5 Released for Testing

Who's Online

Donat-O-Meter

Latest GitHub Commits

{{ record.sha.slice(0, 7) }} - {{ record.commit.message | truncate }}