Re: [Tiki-devel] Global variables vs tikiLib::lib() calls

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Global variables vs tikiLib::lib() calls

Cloutier, Philippe (RESSOURCE EXTERNE)

Thank you Brendan.

It would be useful to have more precise numbers (microseconds can add up pretty quick), but I would not oppose an effort to replace global singleton variables with calls to tikilib::lib().

 

Philippe Cloutier
Développeur/configurateur Tiki

Service des systèmes d’information du Registre foncier

Direction des systèmes d’information

Direction générale du soutien aux opérations

Ministère de l'Énergie et des Ressources naturelles

Québec (Québec)  G1H 6R1

Téléphone : 418 627-6282, poste 2209

philippe.cloutier.externe@...
mern.gouv.qc.ca

 

De : Brendan Ferguson [mailto:[hidden email]]
Envoyé : 2 mars 2017 22:09
À : Tiki developers <[hidden email]>
Objet : Re: [Tiki-devel] Global variables vs tikiLib::lib() calls (was RE: Globals VS tikiLib and Candian Tikifest)

 

I just ran a number of benchmarks. Calls from tikilib are about 10x slower, but the time is nominal, just microseconds for 1000 iterations, so its not worth bothering with imho.

I don't see any way to deprecate global vars. Ive done it, and Ive seen other code committed over the past few months that have called $tikilib (and perhaps others?) globally.

A quick search revealed 15 global $smarty calls in tiki, and 240 $tikilib calls, but there is probably more. Should we make an effort to replace those, or just keep a closer eye on commits?

Brendan

 

On Fri, Mar 3, 2017 at 5:32 AM, Victor Emanouilov <[hidden email]> wrote:

Guys, my 2 cents:

Global vars are evil for a host of reasons and bringing back 10+ year old programming practice is probably not the best way to go. Brendan, I see your frustration with shared hosts and know how tiki could easily eat resources but I agree with Chealer that it is doubtful how global var usage will make any difference to a static call. The example you mention involves far more code processing than standard lib access. Maybe a xdebug session with memory usage and execution time for each function call and a few breakpoints will reveal why the mentioned {DIV} code was so slow. I'd love to see such a debug output but haven't had time for it. Hope to do it in the not so distant future... but if anyone else had some luck in doing it, please share your results!

Regards,
Victor

 

On 03/02/2017 07:09 PM, Cloutier, Philippe (RESSOURCE EXTERNE) wrote:

Hi,

It would be nice to see numbers, but I also find intentionally changing lib() calls with global variables doubtful. I agree that the coexistence of both approaches is not optimal, but I believe the idea was to migrate to lib() calls only (obviously, that won’t be completed overnight).

 

I do not see an issue with different instances. The classes concerned should be singletons. The instance referred to by a global variable should be identical to that obtained by a lib() call.

 

Philippe Cloutier
Développeur/configurateur Tiki

Service des systèmes d’information du Registre foncier

Direction des systèmes d’information

Direction générale du soutien aux opérations

Ministère de l'Énergie et des Ressources naturelles

Québec (Québec)  G1H 6R1

Téléphone : <a href="tel:(418)%20627-6282" target="_blank">418 627-6282, poste 2209

philippe.cloutier.externe@...
mern.gouv.qc.ca

 

De : Brendan Ferguson [[hidden email]]
Envoyé : 2 mars 2017 08:59
À : Tiki developers [hidden email]
Objet : [Tiki-devel] Globals VS tikiLib and Candian Tikifest

 

Jonny Writes:

 

Re the globals vs the static lib function call, i agree it does seem somewhat illogical, all i can say is it was introduced and started by a far better coder than i, so i was just trying to keep his work going. Maybe we should have a special case for $smarty, and maybe $tikilib as these are used almost everywhere and in combination reverting to using globals might have a slight effect on performance, but generally Tiki has way too many globals (you should have seen it before this was started!) which leads to garbled spaghetti code and therefore errors and bugs that can probably be avoided, so the slight hit on performance is, i think, better than failure and unpredictable behaviour... but maybe we should discuss this on the dev list?

 

Ya, I agree. I was looking at even the globals in preferences and thought that it would be good to break those down by feature, so if calendar is not enabled, the globlals for it are not held in memory, etc. I agree with the idea, but if we DO have the global in memory is IS faster to load it that way. The issue with the parser is not so much memory as it is execution time.

I bench-marked 100 Iterations of {DIV()}test{DIV()}test{DIV}{DIV} at 1.1 seconds (php7 & OPcache)  or at 1.7 seconds with PHP5.6 & OPcache) on my system. Other simple plugins have very similar performance.

That is SUPER slow, and its forced me to to enable HTML on many pages that would have used for example, a couple thousand div and other simple html plugins. I really don't like doing that as it brings with it a much higher security risk, and I lose an huge amount of control over what can be put into pages, but I currently have no other option. I was already kicked off one shared hosting companies server because my plugin-rich tiki pages were crashing the server.

Ive go another project on hold, as the tiki-parser cant handle it, but I think the only solution to that particular issue is to do a complete re-write of the parser... something im not up for.

 

So I get that we need to reduce global variables, and that using the auto-loading libraries is a good idea in general, but it does reduce execution time slightly every time we do that. Its nominal in most cases, but does have a slight impact in situations where the var is called multiple times.

Anyhow, long story short, it makes zero sense to have $tikilib and $smarty in global space and then call them through Tikilib::lib('tiki'), which is lower, and could create more memory. Im up for making an exception to these two, as they are called a lot in tiki, but if we are not going to, we should remove them from global memory and call them through Tikilib::lib('tiki')-Tikilib::lib('smarty'), doing both is the worst of the three options, imho.

I guess the other consideration is that calling a new instance of a class can produce slightly different logic in some cases... so that should also be considered, but it needs to call upon vars withing the class for that to be true.

Any thoughts on this subject from others?

 


Thanks again, my Skype and phone number follow if you ever want to discuss this kind of thing in the future, and/or maybe you can come along to our round table meetings and we can chat about the best ways of using our limited volunteer resources?

Even better let's try and do a TikiFest somewhere near you (the US/Canada?) and we can share a beer or whatever (on me! :)

 

I would like that. I am at the end of my Japan trip now, and heading back to Canada on the 4th, I unfortunately dont have a laptop, cause that 24hr flight is a perfect time to code :( I live in Niagara Falls, Ontario, Canada; Toronto, Ontario, Canada; Northern Bruce Peninsula, Ontario Canada, and Kyotanabe, Kyoto, Japan; so any tikifest around those areas is great. I can host in Niagara Falls and Northern Bruce Peninsula locations comfortably.

Brendan

 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

 

_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel