From: Eric Wong <firstname.lastname@example.org> To: Jean Boussier <email@example.com> Cc: firstname.lastname@example.org Subject: Re: [PATCH] Add early hints support Date: Thu, 16 Jul 2020 12:16:43 +0000 [thread overview] Message-ID: <20200716121643.GA26942@dcvr> (raw) In-Reply-To: <242F0859-0F83-4F14-A0FF-5BE392BB01E6@shopify.com> Jean Boussier <email@example.com> wrote: > Thanks for the very timely response. > > > Since this RDoc ends up on the website, links to any relevant > > Rails documentation and RFC 8297 would also be appropriate. > > Otherwise non-Rails users like me might have no clue what > > it's for. > > I updated the documentation, let me know what you think of it. It's fine, pushed for now. Will release in a few days or a week in case there's comments from others. > > Are the method calls for .to_s necessary? > > I don't think they are, I mostly took inspiration from the puma implementation > that does all this defensive checks. Based on how that interface is > used by Rails, we could assume both keys and values are strings already. > > I simplified the implementation. OK. > > Eep, extra branch... What's the performance impact for existing > > users when not activated? (on Unix sockets). > > Extremely small. Alright, numbers would've been helpful but I'll take your word for it. If we get more branches in the main loop for other new features; I wonder if generating the code for process_client dynamically at initialize-time is worth it to avoid branches in the main loop... (or if there's some way to hint MJIT to do that). > > Perhaps bypassing the method and accessing the @early_hints ivar > > directly can be slightly faster w/o method dispatch. That > > should also allow using attr_writer instead of attr_accessor, > > I think. > > attr_reader is very optimized in MRI, it's barely slower than @early_hints. > Also it ensure that it doesn't emit a warning in verbose mode if the variable > isn't initialized. Thanks again.
next prev parent reply other threads:[~2020-07-16 12:16 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-16 10:05 Jean Boussier 2020-07-16 10:50 ` Eric Wong 2020-07-16 11:41 ` Jean Boussier 2020-07-16 12:16 ` Eric Wong [this message] 2020-07-16 12:24 ` Jean Boussier 2020-07-17 1:19 ` Eric Wong 2020-07-20 9:18 ` Jean Boussier 2020-07-20 10:09 ` Eric Wong 2020-07-20 10:27 ` Jean Boussier 2020-07-20 10:55 ` Eric Wong 2020-07-20 11:53 ` Jean Boussier 2020-07-20 20:27 ` Eric Wong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://yhbt.net/unicorn/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200716121643.GA26942@dcvr \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] Add early hints support' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: ../../unicorn.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).