[Tiki-devel] Globals VS tikiLib and Candian Tikifest

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

[Tiki-devel] Globals VS tikiLib and Candian Tikifest

Brendan Ferguson
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] Candian Tikifest [was Re: Globals VS tikiLib and Candian Tikifest]

Jonny Bradley-4
Hi Brendan,

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. 

I'd be game for a Canadian trip sometime - it's been a while! I guess we'd be talking next year now to give enough time to get something like this together. Bruce Peninsula looks amazing but maybe a little remote? Niagara Falls might be more accessible and might even tempt some of our US Tikizens to come and join in?

Also, maybe we can combine this with something in Montreal and/or Ottawa?

Sounds like fun!

Thanks :)

jonny




On 2 Mar 2017, at 13:59, Brendan Ferguson <[hidden email]> wrote:

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] Candian Tikifest [was Re: Globals VS tikiLib and Candian Tikifest]

Jean-Marc Libs
+1 !!!! :-)

On Fri, Mar 3, 2017 at 12:48 PM, Jonny Bradley <[hidden email]> wrote:
Hi Brendan,

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. 

I'd be game for a Canadian trip sometime - it's been a while! I guess we'd be talking next year now to give enough time to get something like this together. Bruce Peninsula looks amazing but maybe a little remote? Niagara Falls might be more accessible and might even tempt some of our US Tikizens to come and join in?

Also, maybe we can combine this with something in Montreal and/or Ottawa?

Sounds like fun!

Thanks :)

jonny




On 2 Mar 2017, at 13:59, Brendan Ferguson <[hidden email]> wrote:

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] Candian Tikifest [was Re: Globals VS tikiLib and Candian Tikifest]

lindon-4
In reply to this post by Jonny Bradley-4
Yes, I’d be tempted!
Regards,
lindon

On Mar 3, 2017, at 6:48 AM, Jonny Bradley <[hidden email]> wrote:

Hi Brendan,

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. 

I'd be game for a Canadian trip sometime - it's been a while! I guess we'd be talking next year now to give enough time to get something like this together. Bruce Peninsula looks amazing but maybe a little remote? Niagara Falls might be more accessible and might even tempt some of our US Tikizens to come and join in?

Also, maybe we can combine this with something in Montreal and/or Ottawa?

Sounds like fun!

Thanks :)

jonny




On 2 Mar 2017, at 13:59, Brendan Ferguson <[hidden email]> wrote:

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] Candian Tikifest [was Re: Globals VS tikiLib and Candian Tikifest]

Brendan Ferguson
In reply to this post by Jean-Marc Libs
While the northern Bruce Peninsula location would be hosted at a luxury cottage. It's rented while summer is out but is available otherwise. It sleeps 9 comfortably, but more is posable, so everyone who wants to come could stay for a few days. Its waterfront and has all the trimmings for a fun vacation, watercraft etc. Spring and fall are really nice there. High speed internet, privacy, wood stove, Firepit, patio BBQ etc. If people wanted to do a day of sight seeing and a day of coding (or something like that, it might be fun. I would be up for 2-4 days of that. It's kinda a long drive for 1 day and it's such a nice location, I just can't force myself to leave after a day, unless I really don't have any other options. There is lots to see and do. I might even be able to introduce everyone to my flying squirrel friends, if we're up late enough. 

Niagara Falls location is smaller. Sleeping area is limited, but there is plenty of couches and I can bring out inflatable mattresses for the floors. There is also lots of hotels around if people want that option. The living area-backyard are ok, but it doesn't hold a candle to the northern Bruce Peninsula. The Niagara Falls (the water rather than the city) is also close by, so it's relatively easy to visit. 

It's also just a 10minute drive to the us border, and at the southern most part of Canada, so driving from the us is short. It's also close to the Buffalo and Hamilton airports. Toronto airport is an option as well, but it's another 1.5-3hr drive (depending) 

Brendan

On Mar 3, 2017, at 9:29 PM, Jean-Marc Libs <[hidden email]> wrote:

+1 !!!! :-)

On Fri, Mar 3, 2017 at 12:48 PM, Jonny Bradley <[hidden email]> wrote:
Hi Brendan,

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. 

I'd be game for a Canadian trip sometime - it's been a while! I guess we'd be talking next year now to give enough time to get something like this together. Bruce Peninsula looks amazing but maybe a little remote? Niagara Falls might be more accessible and might even tempt some of our US Tikizens to come and join in?

Also, maybe we can combine this with something in Montreal and/or Ottawa?

Sounds like fun!

Thanks :)

jonny




On 2 Mar 2017, at 13:59, Brendan Ferguson <[hidden email]> wrote:

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] Candian Tikifest [was Re: Globals VS tikiLib and Candian Tikifest]

Jean-Marc Libs
Bruce Peninsula does sound great! I suppose if we combine First Montreal, then Ontario, we can travel together to Bruce Peninsula, which makes reaching the place still part of the TikiFest for those who attend both. :-)

Chers,
J-M

On Fri, Mar 3, 2017 at 4:29 PM, Dr. Sassafras <[hidden email]> wrote:
While the northern Bruce Peninsula location would be hosted at a luxury cottage. It's rented while summer is out but is available otherwise. It sleeps 9 comfortably, but more is posable, so everyone who wants to come could stay for a few days. Its waterfront and has all the trimmings for a fun vacation, watercraft etc. Spring and fall are really nice there. High speed internet, privacy, wood stove, Firepit, patio BBQ etc. If people wanted to do a day of sight seeing and a day of coding (or something like that, it might be fun. I would be up for 2-4 days of that. It's kinda a long drive for 1 day and it's such a nice location, I just can't force myself to leave after a day, unless I really don't have any other options. There is lots to see and do. I might even be able to introduce everyone to my flying squirrel friends, if we're up late enough. 

Niagara Falls location is smaller. Sleeping area is limited, but there is plenty of couches and I can bring out inflatable mattresses for the floors. There is also lots of hotels around if people want that option. The living area-backyard are ok, but it doesn't hold a candle to the northern Bruce Peninsula. The Niagara Falls (the water rather than the city) is also close by, so it's relatively easy to visit. 

It's also just a 10minute drive to the us border, and at the southern most part of Canada, so driving from the us is short. It's also close to the Buffalo and Hamilton airports. Toronto airport is an option as well, but it's another 1.5-3hr drive (depending) 

Brendan

On Mar 3, 2017, at 9:29 PM, Jean-Marc Libs <[hidden email]> wrote:

+1 !!!! :-)

On Fri, Mar 3, 2017 at 12:48 PM, Jonny Bradley <[hidden email]> wrote:
Hi Brendan,

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. 

I'd be game for a Canadian trip sometime - it's been a while! I guess we'd be talking next year now to give enough time to get something like this together. Bruce Peninsula looks amazing but maybe a little remote? Niagara Falls might be more accessible and might even tempt some of our US Tikizens to come and join in?

Also, maybe we can combine this with something in Montreal and/or Ottawa?

Sounds like fun!

Thanks :)

jonny




On 2 Mar 2017, at 13:59, Brendan Ferguson <[hidden email]> wrote:

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



------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Loading...