Closed antoniogamiz closed 4 years ago
After the last commit I have realized:
We can also try and use a different templating system, like Template::Classic.
In Pod::To::HTML too?
We should detach this from Pod::To::HTML, maybe.
I have used Template::Classic here: https://github.com/Raku/Documentable/tree/feat/use-template-classic. Results:
Generating source files 👇 ...
[=======================================================================]100.00%
Generate source files has taken 228.8313913 seconds
Generating Kind::Syntax files 👇 ...
[=======================================================================]100.00%
Generating Kind::Routine files 👇 ...
[=======================================================================]100.00%
Generating per kind files has taken 180.3566868 seconds
Generating indexes...
Generating index files has taken 10.72521574 seconds
Writing search file...
Generating entries
Writing all generated files 🙌 ...
[#######################################################################]100.00%
Writing generated files has taken 0.8260129 seconds
Whole process has taken 429.9028253 seconds
It's a bit less than even pre-population + template caching, correct?
I noticed Template::Mustache
and performance mentioned under the same context and perhaps can give a useful tip. I don't know where exactly the performance suffers the most in this case, but the latest module implementation supports .hyper/.race
on rows
:
%data<rows> = (gather { ...; take { :$record } }).hyper;
I use it this way in Vikna
in a tool which produces HTML out of a sqlite.
It's a bit less than even pre-population + template caching, correct?
Both develop
and feat/use-template-classic
implements pre-popultation + template caching. In the first one, pre-population is made by Template::Mustache
(and by that reason, it does not work, see https://github.com/softmoth/raku-Template-Mustache/issues/36). In the other, it's made by Template::Classic
.
In that particular case, it seems faster, but it should take the same amount of time (approx) because once templates are pre-populated, all the work is made by Pod::To::HTML
.
I noticed
Template::Mustache
and performance mentioned under the same context and perhaps can give a useful tip. I don't know where exactly the performance suffers the most in this case, but the latest module implementation supports.hyper/.race
onrows
:%data<rows> = (gather { ...; take { :$record } }).hyper;
I use it this way in
Vikna
in a tool which produces HTML out of a sqlite.
I tried to use parallelism to generate the HTML pages but the problem is that Template::Mustache
is used inside Pod::To::HTML
, which does not support parallelism 1.
1 As a curiosity, today is the anniversary of that issue.
I noticed
Template::Mustache
and performance mentioned under the same context and perhaps can give a useful tip. I don't know where exactly the performance suffers the most in this case, but the latest module implementation supports.hyper/.race
onrows
:%data<rows> = (gather { ...; take { :$record } }).hyper;
I use it this way in
Vikna
in a tool which produces HTML out of a sqlite.
I have tried once again, just in case, but it's still failing:
use Pod::Load;
use Pod::To::HTML;
my $pod = load("Endian.pod6")[0];
my @works = [];
for 1..255 { @works.push: $pod }
@works.race.map({
render($pod)
})
After creating the default template, generation time has increased up to 30 minutes, which is a big problem. I have come up with the following solution: