Why is there an LRU cache in the example deck from the gallery (pytest-its-whats-for-testing)?

[edrogers]

Alternate title: "When a Slide has a callable 'content' kwarg, when is that content called?"

While looking through the pytest-its-whats-for-testing source for some inspiration, I stumbled across this unexpected use of LRU cache. After puzzling on it for a while now, I'm really stumped as to why it's there.

Shouldn't each trigger have a unique, monotonic timestamp? When would we expect a cache hit here?

I might be bumping into a limitation of not understanding what's going on in textual with its concept of renderables

[JoshKarpel]

Good question... I made a ticket to write a docs page on Triggers and how/when slides are rendered #187. Also note #179 , which might roll this particular use-case into something with first-class support.

So, the goal of that LRU cache is to prevent run_pytest(path, extra_args, code, start) from being called every time the slide is rendered. Only path and extra_args are actually used by run_pytest(); the other two arguments are only used to break the LRU cache when desired.

run_pytest() is called here https://github.com/JoshKarpel/pytest-its-whats-for-testing/blob/ada03fc54c92c90a1f18ced4b80dca4cab56f7b4/pytest_its_whats_for_testing/slides.py#L74 , with code=<the code in the main example file which can be edited> and start=triggers[0].

• The code argument makes sure that run_pytest will run again if the code in the example file changes; I didn't really end up using this during the talk, but if I had edited an example file, that would ensure it gets re-run after saving the changes.
• triggers[0] is the first trigger time. Each slides gets triggered once when it starts being displayed, and triggers are reset each time you change slides, so triggers[0] is the the time that the slide started being displayed. That'll be a constant as long as you're on the slide.

Now, in terms of when the Slide.content function is called, it's a lot of times. When we're displaying a slide, we update the trigger state 60 times per second

spiel/spiel/widgets/slide.py

Lines 20 to 28 in b6d4582

	triggers: Triggers = reactive(Triggers.new) # type: ignore[assignment,arg-type]
	def on_mount(self) -> None:
	super().on_mount()
	self.set_interval(1 / 60, self.update_triggers)
	def update_triggers(self) -> None:
	self.triggers = Triggers(now=monotonic(), _times=self.triggers._times)

, and the trigger state is a Textual reactive. This is so that you keep getting the now value updated - the trigger times themselves would stay the same from call to call until you trigger the slide. Because the trigger state is a reactive, any change causes the widget it is on to repaint, which calls SlideWidget.render, which ends up calling Slide.render, which calls the Slide.content function. So that's at least 60 calls per second, plus anything else that makes the widget repaint/refresh.

So: you get a cache hit as long as:

• You're still on the same "instance" of rendering the slide (triggers[0] is the same).
• The main example file contents haven't changed.

Without the LRU cache, we'd instead call run_pytest() every time Slide.render() was called.

Hope that answers your question! I'd definitely rate it as a hack on top of the underlying trigger system right now - I'm hoping I'll figure out a better, less-hacky way to integrate executable examples in #179 .