[Tiki-devel] Global variables vs tikiLib::lib() calls (was RE: Globals VS tikiLib and Candian Tikifest)

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Tiki-devel] Global variables vs tikiLib::lib() calls (was RE: Globals VS tikiLib and Candian Tikifest)

Cloutier, Philippe (RESSOURCE EXTERNE)

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 : 418 627-6282, poste 2209

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

 

De : Brendan Ferguson [mailto:[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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Global variables vs tikiLib::lib() calls (was RE: Globals VS tikiLib and Candian Tikifest)

Victor Emanouilov

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 : 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Global variables vs tikiLib::lib() calls (was RE: Globals VS tikiLib and Candian Tikifest)

Dr. Sassafras
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" value="+14186276282" target="_blank">418 627-6282, poste 2209

philippe.cloutier.externe@mern.gouv.qc.ca
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Global variables vs tikiLib::lib() calls (was RE: Globals VS tikiLib and Candian Tikifest)

Jonny Bradley-4

I think i agree (with Victor and Chealer, thanks for the support ;) and maybe there are performance problems with the plugins and parser that can be improved - we know there are limits to nesting them for instance due to the plugin parser - Luci, didn't you find that a while back?

In the past when we've had important complicated pages with hundreds of DIVs in (i've not seen thousands but i guess it might be possible) then it's usually not "user generated" content but a specific "application" interface, and the best way usually to do that imho is in a smarty template anyway, so you get the best of both worlds - wiki plugin goodness and access to the database when needed but otherwise you can use plain html, which is all then cached by smarty and can be server up quicky-quick, so can support scaling and large amounts of traffic (also you can use your own version control, syntax highlighting etc).

Wiki pages certainly have their limitations, but also their strengths so it's important to know when to bail out of them when necessary and find a more efficient method sometimes...

My 2¢ :)

jonny


> On 3 Mar 2017, at 03:09, Brendan Ferguson <[hidden email]> wrote:
>
> 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 : 418 627-6282, poste 2209
>>>
>>> [hidden email]
>>> mern.gouv.qc.ca
>>>
>>>  
>>>
>>> De : Brendan Ferguson [mailto:[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


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Global variables vs tikiLib::lib() calls (was RE: Globals VS tikiLib and Candian Tikifest)

luciash d' being
Hi,


On 03/03/2017 12:39 PM, Jonny Bradley wrote:
> I think i agree (with Victor and Chealer, thanks for the support ;) and maybe there are performance problems with the plugins and parser that can be improved - we know there are limits to nesting them for instance due to the plugin parser - Luci, didn't you find that a while back?

Yes. Here: https://dev.tiki.org/item5697?from=User
I think we agreed it should be optional preference in control panels
(Probably Text area and Wiki plugins) where on more powerful servers one
could set up higher value of nesting when necessary... Still on my todo
list...

luci


> In the past when we've had important complicated pages with hundreds of DIVs in (i've not seen thousands but i guess it might be possible) then it's usually not "user generated" content but a specific "application" interface, and the best way usually to do that imho is in a smarty template anyway, so you get the best of both worlds - wiki plugin goodness and access to the database when needed but otherwise you can use plain html, which is all then cached by smarty and can be server up quicky-quick, so can support scaling and large amounts of traffic (also you can use your own version control, syntax highlighting etc).
>
> Wiki pages certainly have their limitations, but also their strengths so it's important to know when to bail out of them when necessary and find a more efficient method sometimes...
>
> My 2¢ :)
>
> jonny
>
>
>> On 3 Mar 2017, at 03:09, Brendan Ferguson <[hidden email]> wrote:
>>
>> 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 : 418 627-6282, poste 2209
>>>>
>>>> [hidden email]
>>>> mern.gouv.qc.ca
>>>>
>>>>  
>>>>
>>>> De : Brendan Ferguson [mailto:[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
>
> ------------------------------------------------------------------------------
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Global variables vs tikiLib::lib() calls (was RE: Globals VS tikiLib and Candian Tikifest)

Dr. Sassafras
In my case I would like to have user edited books. So the content would be perhaps not user generated, but it could be, say in the case of a user book translation. Each chapter would occupy a page, which is user editable. Some books would be 100pages, others would be 1000 or more. Some would have bite sized chapters, others maybe 8-10, so one could easily have 500 paragraphs on a page, perhaps more. There would be paragraph numbering, footnotes, and other links and formatting in each paragraph (normally).

I'm hesitant to break up chapters into separate pages for performance issues. Causes confusion when reading the book.

I've been thinking along these lines:

Ability to shut down parts of the parser, like removing the ability to parse smilies, and removing the general tiki formatting parsing like bold and underline etc.

If I could enable-disable parts of the parser that I needed, I could probably gain a lot of leeway.

Then it would be amazing if the tiki-interface could use <b> and <I> etc. Tags for formatting, so I'm not loosing the user interface.

Plugins I can already enable-disable so that is great.

But I would like the ability to choose what HTML people can insert. So I might perhaps disable <img> in favour of the image plugin. Etc.

Whitelisting HTML would also take care of my security concerns with allowing HTML code, as it would just be a handful of tags that would be allowed.

The website would start with maybe 100 books and quickly expand to a couple thousand.

I've got one website with a single book, and it really pushes the limits of tiki. It's posable with me micro-managing it. 100 books wouldn't be feasible.

It would also need to handle heavy traffic, as it would be replacing an existing website, which is actually using gopher for half its processes because it's 10x faster than apache, and 10 apache servers is over budget.

Anyhow, that's enough babbling.

Brendan


> In the past when we've had important complicated pages with hundreds of DIVs in (i've not seen thousands but i guess it might be possible) then it's usually not "user generated" content but a specific "application" interface, and the best way usually to do that imho is in a smarty template anyway, so you get the best of both worlds - wiki plugin goodness and access to the database when needed but otherwise you can use plain html, which is all then cached by smarty and can be server up quicky-quick, so can support scaling and large amounts of traffic (also you can use your own version control, syntax highlighting etc).

I'm guessing your talking about a custom smarty template here. What would "your own version control and syntax highlighting look like?

Brendan

>>
>> Wiki pages certainly have their limitations, but also their strengths so it's important to know when to bail out of them when necessary and find a more efficient method sometimes...
>>
>> My 2¢ :)
>>
>> jonny
>>
>>
>>> On 3 Mar 2017, at 03:09, Brendan Ferguson <[hidden email]> wrote:
>>>
>>> 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 : 418 627-6282, poste 2209
>>>>>
>>>>> [hidden email]
>>>>> mern.gouv.qc.ca
>>>>>
>>>>>
>>>>>
>>>>> De : Brendan Ferguson [mailto:[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
>>
>> ------------------------------------------------------------------------------
>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Global variables vs tikiLib::lib() calls (was RE: Globals VS tikiLib and Candian Tikifest)

Victor Emanouilov
In reply to this post by Dr. Sassafras

Hi Brendan,

I don't think an effort to replace those 240 $tikilib calls is needed now. Just keep adding new code in a clean way using the static lib and not replacing static lib calls already there. This seems reasonable to me. As you say, a few calls worth a few microseconds more is not the general problem of your 1.1 seconds page load, so we can concentrate on things that really need optimization and keep coding using best practices.

Thanks for the discussion, I'm sure it makes tiki codebase better which we all would benefit from!

Regards,
Victor


On 03/03/2017 05:09 AM, Brendan Ferguson wrote:
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 moz-do-not-send="true" href="tel:%28418%29%20627-6282" value="+14186276282" target="_blank">418 627-6282, poste 2209

philippe.cloutier.externe@mern.gouv.qc.ca
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

------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Global variables vs tikiLib::lib() calls (was RE: Globals VS tikiLib and Candian Tikifest)

Jonny Bradley-4
In reply to this post by Dr. Sassafras
Hi Brendan,


> On 3 Mar 2017, at 14:12, Dr. Sassafras <[hidden email]> wrote:
>
> In my case I would like to have user edited books. So the content would be perhaps not user generated, but it could be, say in the case of a user book translation. Each chapter would occupy a page, which is user editable. Some books would be 100pages, others would be 1000 or more. Some would have bite sized chapters, others maybe 8-10, so one could easily have 500 paragraphs on a page, perhaps more. There would be paragraph numbering, footnotes, and other links and formatting in each paragraph (normally).

Ah right, hence the work on the footnotes (for which thanks, although i don't really use them)

Are you finding problems with paragraph parsing? I thought that should be fine, or are you using plugins for each one?

> I'm hesitant to break up chapters into separate pages for performance issues. Causes confusion when reading the book.
>
> I've been thinking along these lines:
>
> Ability to shut down parts of the parser, like removing the ability to parse smilies, and removing the general tiki formatting parsing like bold and underline etc.

Smilies should already only be processed if enabled (feature_smileys i think), i'm not sure not processing character styles would save much time, but i guess running some profiling on it would reveal where the blockages are.

> If I could enable-disable parts of the parser that I needed, I could probably gain a lot of leeway.
>
> Then it would be amazing if the tiki-interface could use <b> and <I> etc. Tags for formatting, so I'm not loosing the user interface.
>
> Plugins I can already enable-disable so that is great.
>
> But I would like the ability to choose what HTML people can insert. So I might perhaps disable <img> in favour of the image plugin. Etc.
>
> Whitelisting HTML would also take care of my security concerns with allowing HTML code, as it would just be a handful of tags that would be allowed.

I'm not sure the current parser could safely be extended to do that, and as you said before developing a new one is a monumental task (we're just about to remove the last one, sadly)

> The website would start with maybe 100 books and quickly expand to a couple thousand.
>
> I've got one website with a single book, and it really pushes the limits of tiki. It's posable with me micro-managing it. 100 books wouldn't be feasible.
>
> It would also need to handle heavy traffic, as it would be replacing an existing website, which is actually using gopher for half its processes because it's 10x faster than apache, and 10 apache servers is over budget.
>
> Anyhow, that's enough babbling.

still more below :)

> Brendan
>
>
>> In the past when we've had important complicated pages with hundreds of DIVs in (i've not seen thousands but i guess it might be possible) then it's usually not "user generated" content but a specific "application" interface, and the best way usually to do that imho is in a smarty template anyway, so you get the best of both worlds - wiki plugin goodness and access to the database when needed but otherwise you can use plain html, which is all then cached by smarty and can be server up quicky-quick, so can support scaling and large amounts of traffic (also you can use your own version control, syntax highlighting etc).
>
> I'm guessing your talking about a custom smarty template here. What would "your own version control and syntax highlighting look like?

Yes, these are custom tpl files usually stored in the themes/mytheme/templates dir or just themes/templates/, and i personally use my own svn server (most people use GitHub or butbucket and git) and then create a symlink from my client work dir to the tiki themes dir (and add that in the admin/security "Extra smarty directories" pref.

I committed a few from a shopping cart project in templates/examples/shop a few tikis ago, but they probably need updating now!

Gottago, thanks for all your enthusiasm and hard work!

jonny



> Brendan
>
>>>
>>> Wiki pages certainly have their limitations, but also their strengths so it's important to know when to bail out of them when necessary and find a more efficient method sometimes...
>>>
>>> My 2¢ :)
>>>
>>> jonny
>>>
>>>
>>>> On 3 Mar 2017, at 03:09, Brendan Ferguson <[hidden email]> wrote:
>>>>
>>>> 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 : 418 627-6282, poste 2209
>>>>>>
>>>>>> [hidden email]
>>>>>> mern.gouv.qc.ca
>>>>>>
>>>>>>
>>>>>>
>>>>>> De : Brendan Ferguson [mailto:[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
>>>
>>> ------------------------------------------------------------------------------
>>> 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


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tiki-devel] Global variables vs tikiLib::lib() calls (was RE: Globals VS tikiLib and Candian Tikifest)

Dr. Sassafras
>
> Are you finding problems with paragraph parsing? I thought that should be fine, or are you using plugins for each one?

Ya. Paragraph parsing while using HTML mode is terrable. That's because spacing is not preserved while in HTML mode when using plugins. Spacing is rendered differently according to several factors:

White space (including a space) will render into a return if it is on the beginning of a plugin data call that uses parse_data(), but won't if parse_data is not called, even if wiki is being evaluated. Some plugin designers use trim($data) to help solve this, but it's not sufficient because it strips the first space from within a plugin call, even when it's needed.

There are also several situations where paragraph spacing will fail to render, or be insert into the wrong place for several inconsistent reasons. I can't remember all the reasons, but using two line breaks on the first paragraph (I think if I remember correctly) helps to render paragraph spacing in a plugin (some of them) if there is multiple paragraphs.  Otherwise paragraph spacing won't be rendered at all. I've tweaked my CSS to help account for the difference in the first paragraph vs the second one (to try and make them look the same)

A trick (for a different issue) I used in the footnotes plugin, was to search for an opening <p> and tender it inline-block if it exists. Parsing will sometimes place content within paragraphs, and sometimes not. This leads, in the case of footnotearea), to what looks like broken spacing(the "1." On a line up, as the block level <p> pushes content into a new line) if nothin is done about it. I see the quote plugin does not evaluate $data properly and I wonder if it's because of this issue, which it would also surely suffer from, as quotes might sometimes display with an opening paragraph.

It makes matters worse that how a particular plugin chooses to render the data is left up to the plugin designer. There is about 5 different ways in which plugins render wiki, all of which result in slightly different outputs. Some built in options that will correctly (or at least consistently) render wiki-HTML would be really helpful.

I will file bug reports on them all when I get the chance.

Thanks for the explanation about the version control. I never would have thought of using a symlink there. That could be a really helpful suggestion!

Brendan

>
>> I'm hesitant to break up chapters into separate pages for performance issues. Causes confusion when reading the book.
>>
>> I've been thinking along these lines:
>>
>> Ability to shut down parts of the parser, like removing the ability to parse smilies, and removing the general tiki formatting parsing like bold and underline etc.
>
> Smilies should already only be processed if enabled (feature_smileys i think), i'm not sure not processing character styles would save much time, but i guess running some profiling on it would reveal where the blockages are.
>
>> If I could enable-disable parts of the parser that I needed, I could probably gain a lot of leeway.
>>
>> Then it would be amazing if the tiki-interface could use <b> and <I> etc. Tags for formatting, so I'm not loosing the user interface.
>>
>> Plugins I can already enable-disable so that is great.
>>
>> But I would like the ability to choose what HTML people can insert. So I might perhaps disable <img> in favour of the image plugin. Etc.
>>
>> Whitelisting HTML would also take care of my security concerns with allowing HTML code, as it would just be a handful of tags that would be allowed.
>
> I'm not sure the current parser could safely be extended to do that, and as you said before developing a new one is a monumental task (we're just about to remove the last one, sadly)
>
>> The website would start with maybe 100 books and quickly expand to a couple thousand.
>>
>> I've got one website with a single book, and it really pushes the limits of tiki. It's posable with me micro-managing it. 100 books wouldn't be feasible.
>>
>> It would also need to handle heavy traffic, as it would be replacing an existing website, which is actually using gopher for half its processes because it's 10x faster than apache, and 10 apache servers is over budget.
>>
>> Anyhow, that's enough babbling.
>
> still more below :)
>
>> Brendan
>>
>>
>>> In the past when we've had important complicated pages with hundreds of DIVs in (i've not seen thousands but i guess it might be possible) then it's usually not "user generated" content but a specific "application" interface, and the best way usually to do that imho is in a smarty template anyway, so you get the best of both worlds - wiki plugin goodness and access to the database when needed but otherwise you can use plain html, which is all then cached by smarty and can be server up quicky-quick, so can support scaling and large amounts of traffic (also you can use your own version control, syntax highlighting etc).
>>
>> I'm guessing your talking about a custom smarty template here. What would "your own version control and syntax highlighting look like?
>
> Yes, these are custom tpl files usually stored in the themes/mytheme/templates dir or just themes/templates/, and i personally use my own svn server (most people use GitHub or butbucket and git) and then create a symlink from my client work dir to the tiki themes dir (and add that in the admin/security "Extra smarty directories" pref.
>
> I committed a few from a shopping cart project in templates/examples/shop a few tikis ago, but they probably need updating now!
>
> Gottago, thanks for all your enthusiasm and hard work!
>
> jonny
>
>
>
>> Brendan
>>
>>>>
>>>> Wiki pages certainly have their limitations, but also their strengths so it's important to know when to bail out of them when necessary and find a more efficient method sometimes...
>>>>
>>>> My 2¢ :)
>>>>
>>>> jonny
>>>>
>>>>
>>>>> On 3 Mar 2017, at 03:09, Brendan Ferguson <[hidden email]> wrote:
>>>>>
>>>>> 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 : 418 627-6282, poste 2209
>>>>>>>
>>>>>>> [hidden email]
>>>>>>> mern.gouv.qc.ca
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> De : Brendan Ferguson [mailto:[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
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>
>
> ------------------------------------------------------------------------------
> 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
Loading...