The contextmanager decorator creates a new context manager every
time its run, but since we only have a single context var, we can
use the same one every time. Creating the contextmanager was roughly
20% of the time time of the template render
I was a bit suprised to find it creates a new context manager
object every time https://stackoverflow.com/questions/34872535/why-contextmanager-is-slow
* Allow specifying a custom log function for template render
* Bypass template cache when reporting errors + fix tests
* Send errors as events
* Fix logic for creating new TemplateEnvironment
* Add strict mode back
* Only send error events if report_errors is True
* Force test of websocket_api only
* Debug test
* Run pytest with higher verbosity
* Timeout after 1 minute, enable syslog output
* Adjust timeout
* Add debug logs
* Fix unsafe call to WebSocketHandler._send_message
* Remove debug code
* Improve test coverage
* Revert accidental change
* Include severity in error events
* Remove redundant information from error events
* Fix memory churn in state templates
The LRU for state templates was limited to 512 states. As soon
as it was exaused, system performance would tank as each template
that iterated all states would have to create and GC any state
> 512
* does it scale?
* avoid copy on all
* comment
* preen
* cover
* cover
* comments
* comments
* comments
* preen
* preen
* Adds a loader to enable jinja imports.
* Switch to in-memory
* Move loading custom_jinja off of the event loop
* Raise TemplateNotFound if template doesn't exist
* Fix docstring
* Adds a service to reload custom jinja
* Remove IO from test setup
* Improve coverage and small refactor
* Incorporate feedback and use .jinja extension
* Check the loaded sources in test.
* Incorporate PR feedback.
* Update homeassistant/helpers/template.py
Co-authored-by: Erik Montnemery <erik@montnemery.com>
---------
Co-authored-by: Erik Montnemery <erik@montnemery.com>
When a template render raised an exception we would start listening for
all states until the template did not raise an exception anymore. This
was not needed since the entity that is causing the exception was
already in the tracker.
Re-rendering on all state changes can be extremely expensive and can
bring an instance into a sluggish or unresponsive state when updating
from a much older version that did not raise ValueError when a default
was missing.
J. Nick Koston
Lars R
Jan-Philipp Benecke
Martijn van der Pol
Jan Bouwhuis
Marc Mueller
Raman Gupta
Erik Montnemery
David Poll
Petro31
ehendrix23
Lucas Mindêllo de Andrade
epenet
Franck Nijhof
Vaarlion
Michaël Arnauts