Internal section/components caching

underfisk

I've been using JSReport for a while and something that I'm curious about (whether it is an opt-in config value or just by default) is a way to cache section/components artifacts.
A practical example would be:
Given a report that is composed of 3 sections(or components, not sure of the actual term), if only 1 section (data/dependencies) changes, I would want that the other 2 unchanged sections/component's final output/artifact is cached(or memoized) and it would just hydrate the changed piece and probably speed up the time it takes to generate.

Not sure if the example above describes really well what I'm trying to achieve/request here but I'm trying to figure out ways to speed up the pdf generation

jan_blaha

The chrome html->pdf conversion is typically the bottleneck and doing optimizations in html generation isn't useful typically.

jsreport caches the handlebars templates and helpers to speed things up. We can't cache the outputs, because you can always have something like new Date() in the template or component.

You could implement some kind of sections cache in the script beforeRender if it makes sense to you.

underfisk

Thanks for getting back to me so fast.
You mentioned that chrome HTML to pdf is not exactly "fast", what are the recommendations to speed it up when we have multiple components per sections and those components are kinda complex?

Another question of mine is basically what's actually faster, external resources vs local resources (CSS, js scripts, images)
I was curious about how the images are loaded when its a local file:

If I request the same file twice, is it cached already, or will it always read directly from the disk?
If we have multiple images, is the loading parallelized?

The questions regarding resources is that within a section that i have, we can generate hundredths of components and often they repeat the same icon multiple times, I'm trying to understand if that's something that JSReport optimizes for us

jan_blaha

jsreport provides to chrome html. This is something that is typically quickly done. You can see in the profiler how much time it takes. Then the pdf rendering is done by chrome and jsreport has no influence on that.

The chrome is a black box for us so I can't give you precise answers. It's likely loading images in parallel. It's likely printing the same image just once... Just try different things and measure the difference.

underfisk

That makes sense, thanks for the quick answers
I'll definitely try beforeRender and possibly post something here to help the others that are probably facing the same questions of mine