Use maud templates and serde_json for directory listings

[palant]

Description

This is essentially the same as #365 but using maud templates. Maud provides a cleaner syntax than sailfish (IMHO), and it doesn’t masquerade as being separate from the code (sailfish templates also use variables which are in scope even when these are outside the template). Local testing indicates no performance difference here either. But unlike sailfish, using maud doesn’t result in additional whitespace.

Downside: maud is for HTML only, JSON logic remains as it was. Then again, maybe it’s better to just go to serde_json for a cleaner JSON generation approach.

How Has This Been Tested?

Integration tests pass. Functional testing on Linux is also fine.

[semanticdiff-com]

Review changes with SemanticDiff.

Analyzed 1 of 3 files.

Overall, the semantic diff is 5% smaller than the GitHub diff.

	Filename	Status
❔	Cargo.lock	Unsupported file format
❔	Cargo.toml	Unsupported file format
✔️	src/directory_listing.rs	4.59% smaller

[joseluisq]

JSON logic remains as it was. Then again, maybe it’s better to just go to serde_json for a cleaner JSON generation approach.

Yes, serde_json can do the job, go for it.

[palant]

Yes, serde_json can do the job, go for it.

Separate PR once this is merged then.

[palant]

Added change to the JSON-formatted directory listings to this PR after all, would have been a fat merge conflict otherwise. Performance is minimally improved in local tests, around 2%.

Originally I used an intermediate data structure for JSON serialization. It made sense to serialize FileEntry directly however. So some fields had to be renamed and types changed here.

[palant]

Added change to the JSON-formatted directory listings to this PR after all, would have been a fat merge conflict otherwise. Performance is minimally improved in local tests, around 2%.

This caused an unexpected performance regression for HTML listings, both large and small. This makes little sense, trying to figure out what’s going on there.

[palant]

It’s a performance regression that cannot be reproduced locally. And flamegraph only shows that a bulk of the time is taken up by chrono and humansize calls but these didn’t change.

[palant]

Of course I cannot reproduce a performance regression locally if it isn’t caused by this change. 🙄

The performance regression first shows up when current development is merged into this branch. Looking into the changes, #360 appears to be the culprit.

[joseluisq]

The performance regression first shows up when current development is merged into this branch. Looking into the changes, #360 appears to be the culprit.

Yeah, It can be due to the dynamic compression.

What I noted in the benchmarks is that the regression is notorious when listing large index. E.g. ~48% latency increase compared to for nginx. But in other tests, we are almost closer to the first two servers.

[palant]

What I noted in the benchmarks is that the regression is notorious when listing large index. E.g. ~48% latency increase compared to for nginx. But in other tests, we are almost closer to the first two servers.

That’s not because of the compression, has nothing to do with this “regression.” We are simply pretty slow at formatting file sizes and modification times.

[joseluisq]

Thanks!