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

HTTP::StaticFileHandler: Reduce max stat calls from 6 to 2 #12310

Merged
merged 2 commits into from
Jul 29, 2022

Conversation

didactic-drunk
Copy link
Contributor

No description provided.

@@ -71,7 +72,7 @@ class HTTP::StaticFileHandler
context.response.content_type = "text/html"
directory_listing(context.response, request_path, file_path)
elsif is_file
last_modified = modification_time(file_path)
last_modified = file_info.not_nil!.modification_time
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the is_file check can be inlined here, so there's no need for not_nil!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah, that's a good alternative to early return.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Compiler nil check error without an early return

context.response.headers["Content-Encoding"] = "gzip"
end
end

context.response.content_length = File.size(file_path)
context.response.content_length = file_info.not_nil!.size
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if file_info is nil? Can that happen at all?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No it can't because the branch is guarded by is_file which require file_info present. not_nil! can still be avoided here, though if we just return early when file_info is nil.

Copy link
Member

@straight-shoota straight-shoota left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good improvement, thanks 👍

How about an early return when file_info is nil? This would allow to remove the newly introduced nil-handling which just makes the code less concise.

Remove not_nil!
@straight-shoota straight-shoota added this to the 1.6.0 milestone Jul 26, 2022
Comment on lines +58 to +59
is_dir = file_info && file_info.directory?
is_file = file_info && file_info.file?
Copy link
Contributor

@Sija Sija Jul 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor suggestion:

Suggested change
is_dir = file_info && file_info.directory?
is_file = file_info && file_info.file?
is_dir = file_info.try(&.directory?)
is_file = file_info.try(&.file?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

&& is an attempt to reduce the type to Bool.

@asterite Does optimize anything?

Copy link
Member

@straight-shoota straight-shoota Jul 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The result of both expression is identical. It's not bool because Nil#&& returns Nil.

See https://crystal-lang.org/reference/1.5/syntax_and_semantics/and.html

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My opinion on these suggestions is that they are just suggestions. It depends on your code style, and the guide says nothing about this. So feel free to pick them up or ignore them.

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants