Agree with the last para.

There is probably a lot that can be done in terms of restructuring some of 
my old SLEs given that some are 5 years old (I regularly cringe at some of 
the code I used back then). Needs a clearer head than I have just now in 
the wee hours.

Getting back to Rich's issue, perhaps if you want to show us your SLE code 
we might be able to give you a few pointers as to how it can be refactored 
to operate more efficiently.

Gary

On Friday, 6 April 2018 00:27:51 UTC+10, Tom Keffer wrote:
>
> I think we're all on the same page here.
>
> The Standard report typically involves 14 file generations, so the 
> function get_extension_list() will be invoked 14 times. If that's taking a 
> long time, I would suggest trying to restructuring the SLE so the 
> get_extension_list() invocation is not so expensive. For example, perhaps 
> the parameters for the invocation could be stored in the object, but not 
> actually do anything unless the tag is used (lazy evaluation). Or, if all 
> 14 of those expensive invocations are identical, put it in __init__(), 
> instead of get_extension_list(), then do it just once and store the results.
>
> Of course, if the expensive calculation needs to be done for every 
> template and they are all different, then there's no way around it. But, I 
> find it hard to imagine such a case.
>
> -tk
>
> On Thu, Apr 5, 2018 at 6:58 AM, gjr80 <[email protected] <javascript:>> 
> wrote:
>
>> Tom,
>>
>> Perhaps I am not understanding you correctly, but I have run into this 
>> issue a number of times with a processing intensive SLE. Whether or not any 
>> of the tags created by the SLE are used, the SLE is run in its entirety for 
>> each template listed in the skin. For example, I have a SLE that returns 
>> some rain related tags and it takes about 1 second for get_extension_list() 
>> to execute. I included this SLE in the search_list_extensions list in the 
>> Standard skin.conf. None of the tags returned by the SLE are used in any 
>> template in the Standard skin, yet during the report cycle the SLE is 
>> invoked 15 times in total taking a little over 15 seconds in total.
>>
>> I can understand that the TimeBinder 'chain' is more efficient in that 
>> time consuming tasks such as db queries only occur if the tag is 'hit', but 
>> not every SLE uses the TimeBinder chain approach. I think that is the issue 
>> Rich is seeing (and I have encountered in the past)
>>
>> Gary
>>
>> On Thursday, 5 April 2018 22:47:06 UTC+10, Tom Keffer wrote:
>>>
>>> Hello, Rich.
>>>
>>> I'm afraid I'm not quite understanding your situation.
>>>
>>> There are 3 different occasions when your SLE may come into play:
>>>
>>>    1. When the Cheetah report generator starts up. This is when your 
>>>    SLE gets instantiated, that is, its __init__ function, if any, gets 
>>>    invoked. This happens only once per report generation.
>>>    2. When a template gets generated. This is when get_extension_list() 
>>>    is invoked, which happens once per template. For the standard search 
>>> list 
>>>    that comes with weeWX, this is when the top of the tag chain (class 
>>>    TimeBinder), described in How tags work 
>>>    <http://weewx.com/docs/customizing.htm#how_tags_work>, gets created, 
>>>    however, the chain itself does not actually get chased. 
>>>    3. When looking for a tag. The Cheetah template engine will probe 
>>>    all the search list extensions looking for a specific tag. It does this 
>>> by 
>>>    calling __getattr__ repeatedly with the tag name as an argument --- a 
>>> cheap 
>>>    call. If it finds a hit, then this is typically when the expensive stuff 
>>>    starts happening. Note that this probing will happen *for every tag*, 
>>>    whether your tag or not. But, the rest of the tag chain gets invoked 
>>> only 
>>>    if Cheetah finds a hit. For the search list that comes with weeWX 
>>> nothing 
>>>    expensive happens until the very end of the tag chain. That's when the 
>>>    database lookups start happening. 
>>>
>>> You say your expensive calculation is happening 14 times. If you have 14 
>>> of your tags sprinkled throughout the templates, then this is unavoidable: 
>>> 14 requests for your tag, 14 calculations.  However, if you expect all 14 
>>> tags to produce the same results (an example would be $station.altitude) 
>>> then you should be doing your calculation farther up the stack described 
>>> above. Perhaps you should be doing the calculation in get_extension_list() 
>>> or even __init__.
>>>
>>> I hope this make sense. If not, give us some more specifics.
>>>
>>> Cheers,
>>>
>>> -tk
>>>
>>>
>>> On Wed, Apr 4, 2018 at 10:26 PM, gjr80 <[email protected]> wrote:
>>>
>>>> Hi Rich,
>>>>
>>>> Unfortunately the SLEs are applied to each report in a skin. Can you 
>>>> pull out the template concerned into its own skin and use the SLE in that 
>>>> skin only? 
>>>>
>>>> Gary
>>>>
>>>>
>>>> On Thursday, 5 April 2018 14:59:13 UTC+10, Rich Altmaier wrote:
>>>>>
>>>>> I'm creating a Report extension which is fairly expensive to 
>>>>> calculate.  When I add my extension to skin.conf, with the usual  
>>>>> search_list_extensions under CheetahGenerator, I find my extension is 
>>>>> invoked about 14 times, which costs many seconds.   Is it possible to 
>>>>> make 
>>>>> a Report extension apply to a selected file generation, such as in 
>>>>> generating index.html only?
>>>>> Thank you!
>>>>> Rich
>>>>>
>>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "weewx-user" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to