Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Efficiency problems after using a full mustache template #117

Closed
antoniogamiz opened this issue Jul 21, 2020 · 10 comments
Closed

Efficiency problems after using a full mustache template #117

antoniogamiz opened this issue Jul 21, 2020 · 10 comments
Assignees
Labels
bug Something isn't working

Comments

@antoniogamiz
Copy link
Collaborator

antoniogamiz commented Jul 21, 2020

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:

After measuring (approximately) the generation times, we get:

Change Time
No changes ~ 1500 seconds (25 minutes)
(sub)menu pre-population ~ 1000 seconds (16 minutes)
pre-population + template caching ~ 500 seconds (8-9 minutes)
  • plus around 3 minutes to create the pod cache.
@antoniogamiz antoniogamiz added the bug Something isn't working label Jul 21, 2020
@antoniogamiz antoniogamiz self-assigned this Jul 21, 2020
@antoniogamiz
Copy link
Collaborator Author

After the last commit I have realized:

@JJ
Copy link
Contributor

JJ commented Jul 22, 2020 via email

@antoniogamiz
Copy link
Collaborator Author

In Pod::To::HTML too?

@JJ
Copy link
Contributor

JJ commented Jul 22, 2020

We should detach this from Pod::To::HTML, maybe.

antoniogamiz added a commit that referenced this issue Jul 22, 2020
We generate around 1700 html files, with basically the same menu and
submenu for every page (except for the selected entry). With this
change, we reduce the processing time of Template::Mustache.
antoniogamiz added a commit that referenced this issue Jul 22, 2020
Now the default template has two different template specifications,
but hey, it's faster.
@antoniogamiz
Copy link
Collaborator Author

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

@JJ
Copy link
Contributor

JJ commented Jul 22, 2020

It's a bit less than even pre-population + template caching, correct?

@vrurg
Copy link

vrurg commented Jul 22, 2020

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.

@antoniogamiz
Copy link
Collaborator Author

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 softmoth/raku-Template-Mustache#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.

@antoniogamiz
Copy link
Collaborator Author

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.

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.

@antoniogamiz
Copy link
Collaborator Author

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.

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)
})

antoniogamiz added a commit that referenced this issue Jul 23, 2020
If you use 'visibility', the contents will expand the parent box leaving
a gap. However, 'display' does not render the div block at all.

Refs: #117
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants