Hi

I remarked that using a smarty plugin generates much overhead - even if compiled!

Take a look at the simple smarty "regex_replace" function (which is nothing more than a simple preg_replace() php function)

smarty_core_load_plugins(array('plugins' => array(array('modifier', 'regex_replace', 'db:system_phpdebug.html', 38, false),)), $this); ?>

This starts a whole bunch of function calls!

Okay, what is the result of all?

function smarty_modifier_regex_replace($string, $search, $replace)
{
return preg_replace($search, $replace, $string);
}



So how can i make this more effective? I want to compile the function inline without the hole plugin-loader thing which seems oversized to me (a bit like the CriteriaCompo and the XoopsObject, but that´s another story ;))

greetings
birdseedmusic

Quote:

Can you expand on this some more please. I work with XoopsObject, Criteria and CriteriaCompo on a daily basis and personally cannot see what you are describing.

The code is, as far as I can see, efficient for what it does. Because of Xoop's OO structure I am able to build modules quicker by taking advantage of persistence, security etc and can concentrate on producing more robust features as opposed to worry about and spend ages debugging/find errors in various includes here and there.

Granted, you can probably squeeze more speed out of a simple include here or there but in the long run your code becomes unyielding, duplicated and eventually a mess.

If I've missed the mark then my appologies.

Cheers.

McNaz.

Hi

anyone can answer my smarty question?






about the criteriacompo:

The CriteriaCompo is a nice thing in order to reduce complexity of SQL Statements, BUT...

There is always a tradeoff between well-structured code and performance. mainfile.php is included in EVERY XOOPS page, so it SHOULD be optimized for speed. this means: simple sql statements. with the new profile, we have a additional join between two tables. we have a complex CriteriaCompo rendering. We have a smarty plugin system which loads plugin files at runtime instead of compiling them. we have a security abstraction class instanciated which does in 99.9% the same as in xoops1, a non-LDAP login.

newbb...when editing or writing a post, i don´t care about the performance. But when READING a post (90% of all access are read access), i would expect that there is a "precompiled" Version of a post where all the text sanitizers, smilie replacement loops and so on are already edited.

I did a newbb hack for xoops1 where all that is done to display a (precalculated) newbb posting is fetching a MySQL text field and putting it out with echo. with the xoops2 update, i have to do this again because noone cared about such things.

Yes, i am talking about milliseconds. Those milliseconds become hours if multiplied by many request per day.

I am in the unhappy position to have high traffic site running with xoops, so I have to care for myself about optimizing the core.

greetings
birdseedmusic

Hi again Birdseed.

Quote:

Doesn't Smarty caching do all of this automatically? The forum I run has a 1 min cache on it and you can see all the prerendered forum posts in the cache directory.

Quote:

There is always a trade of between speed and the amount of storage. In the previous example alot of disk space will be used up to generate static prerendered html for caching.

Quote:

This is always a tricky one I must admit. I always thought that the bigger your site becase the beefier hardware you have to throw at it. Alternatively, you need to optimise your code. How far can you optimise it? PHP has its speed limitation even for the most optimised code. What next? a CMS in C++? C? ASM?

This is where you ask yourself what is cheaper: Buying/renting a bigger server or writing your own C/ASM routines to handle increasing traffic.

Hi

Your arguments are good. Nevertheless, i have to realize that performance in XOOPS is a topic which is generally answered with "turn on smarty caching" ;)

As I am requesting to join the core developer team, it might be MY job to optimize that.

greetings
birdseedmusic

Implement your function as a Smarty compiler plug-in (they do exactly what you complain is missing).



Or something like this.... Read the corresponding part of the Smarty manual

skalpa.>

Quote:
That answer usually comes from advanced users and what else do you expect? Many people use XOOPS who have no idea about classes, functions and SQL statements, so naturally this will be their "rule of everything"
Quote:
Yes, an objective in XOOPS 2.4 will be refinement, performance - and new functionality, depending on the available resources.

However, you should keep in mind that readability of the code is very important in systems that are used as XOOPS is. We have to cater for the people, who want minor modifications and easy upgrade paths. We have to cater for them, even if they have little knowledge about PHP.

Granted, the "enable caching" is not always the good reply, but when speaking of performance, it is imperative to find the bottleneck. Is the bottleneck in the OO structure of XOOPS? Is it in the joins between well-indexed tables? I don't think so. Is it in long processings of unoptimised code? I think we can definitely improve there. Is it in too many and unoptimised SQL queries? Certainly a big area. Is it in the Smarty templating engine? Perhaps, but the benefits are considerable and the workarounds are - as Skalpa stated - present.

Pre-rendering e.g. the texts so that they don't have to go through the text sanitizer's preg_replace calls is something we are discussing and planning for XOOPS 4 - perhaps we can implement improvements in XOOPS 2.4, too. I know, I'd be very interested in hearing your ideas on this - as long as they give the same flexibility as the current code.

The core (and certainly many modules) can be improved, but I think there are better areas to focus on than the OO structure in general and the Criteria, Security and Object classes in particular.

Looking forward to discussing this with you as soon as XOOPS 2.2 stable is out.

You don't need to join the core team to optimize code - just submit your changes a patch on the core development sourceforge site.

You might also want to take a look at the development roadmap for XOOPS 4. Most of what you're complaining about has been addressed there.

Both links are on the left.

You might win milliseconds with your optimizing, but you loose in other areas. The XoopsObject and CriteriaCompo classes aren't just there to make things look neat, they are preparing the way for using non MySQL databases to store the data. And simply "echo"ing text destroys the separation between presentation and logic code, designers won't thank you for doing it.

I like XOOPS because of the goals the team are striving for in the architectural design. I'd hate to see that pushed aside just to gain a few milliseconds.

Hello

First of all, thanks for your long and detailed replies. It must be one the strange rules of online forums that we discuss now about one small "by-the-way" sentence, but I´m familiar with that from my own portal ;)


I know about the difference between echoing html an using templates. I have developed two modules for xoops, one of them quite complex, so I am familiar with the XOOPS concepts and the core.

If you use the xoopsObject as a database abstraction layer, why was it implemented in xoops1, but will not really be used before xoosphere? without all that initvar/getVar/setVar stuff, things could be so easy for me. Even in xoops2, i see:

echo "" . $myvar . ""; (...)

On the other hand, I see many abstraction layers. So this doesn´t fit together for me. Why write an database abstraction for the 5% (guessed?) postgre Users (does postgre work with xoops? never tried...) instead of concentrating on mysql.

The XOOPS core is not clean. Everyone knows it. It is easy to find duplicate code. It is easy to find sql statements in the core where there should be criteria objects and criteriaobjects where there should be sql statements. it is easy to find notice errors and warnings.

Please don´t misunderstand me. I like xoops, i like the XOOPS community. But I´m a bit afraid that in the whole "abstraction layer movement", the small and dirty work - preserving a clean and consistent, fast and error free core - which means optimizing at a low level - is pushed aside.

I´m using XOOPS because I have a - compared to big web companies - a small site. The size and user traffic is comparable to http://www.xoops.org. If my site was bigger, I wouldn´t use xoops, i wouldn´t use php. Instead, I would use a compiled language like java or .NET, i would not be using MySQL but MSSQL Server, Ingres or even oracle. I would be using a cms without any predefined layout. So I wonder if the road(map) that you decided to go is the right one. I´d rather see a xoops2.6 ;)

greetings
birdseedmusic

Hi

Oh my god. So much discussion that I forgot my most important question: ;)

If there is a smarty compiler plugin integration, why the hell did the smarty developers not use it??? Is there any reason for not using compilation for a one-line-code? Okay, a complex validator function should not be compiled inline, but compilation for 1:1 php/smarty functions would have made sense.

greetings
birdseed