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

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.

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

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

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

A quote from your quote.

Network Performance Tips:

Quote:

Quote:

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

Quote:

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

Quote:
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:
Protector Preload?

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:


If you want some deep insight to your XOOPS just copy this to the file where you want to get some information about:


This should be too much of info!