<font size=2 face="sans-serif">Nice work!</font>
<br>
<br><font size=2 face="sans-serif">Taking a quick look at the project and
screenshot, am I right in saying that there is no concurrency in the test?
ARC generally has a bigger impact in concurrent use cases because of the
need to keep memory consistency across processors for the atomic increment/decrement.</font>
<br>
<br><font size=2 face="sans-serif">How hard would it be to add a dispatch
queue in?</font>
<br>
<br><font size=2 face="sans-serif">Chris</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Tanner Nelson via swift-server-dev
<swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Michael Chiu <hatsuneyuji@icloud.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">swift-server-dev <swift-server-dev@swift.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">27/03/2017 14:38</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [swift-server-dev]
Next HTTP API meeting</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">swift-server-dev-bounces@swift.org</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>Re: performance,</font>
<br>
<br><font size=3>I did a quick test of inout struct vs. class performance.
The code can be found here: </font><a href="https://github.com/tanner0101/request-types"><font size=3 color=blue><u>https://github.com/tanner0101/request-types</u></font></a>
<br>
<br><font size=3>I found only a marginal increase in performance (~5%)
in favor of inout value types. </font><a href="https://github.com/tanner0101/request-types/issues/1"><font size=3 color=blue><u>https://github.com/tanner0101/request-types/issues/1</u></font></a>
<br>
<br><font size=3>Additionally, non-inout value types were a lot slower.
This is obvious to the seasoned Swift dev considering each middleware in
the test modifies and thus must copy the request. But this is the exact
type of performance issue you can expect developers to create when interacting
with "non-obvious value types". HTTP request/response being non-obvious
value types compared to something like an integer or a float. (I'd argue
the majority of web developers would expect request/response to be a reference
type and thus easily forget or not know to use `inout`)</font>
<br>
<br><font size=3>Please feel free to submit any prs/issues/comments about
ways I could improve this test to make it more accurate. </font>
<br>
<br><font size=3>tl;dr: value types don't seem much faster than reference
types (especially considering dangers of misuse) in a simulated web framework
scenario</font>
<br>
<br><font size=3>inb4: people saying that the request/response models in
my test are incomplete/not fully implemented/bad. this is _not_ a proposed
api for request/response.</font>
<br>
<br><font size=3 color=#9f9fe0>Va</font><font size=3 color=#b1b1d2>p</font><font size=3 color=#c0c0c0>o</font><font size=3 color=#bfbfbf>r</font><font size=3 color=#9f9fe0>
</font>
<br><a href=mailto:tanner@vapor.codes><font size=3 color=blue><u>tanner@vapor.codes</u></font></a>
<br>
<br><font size=3>On Mar 27, 2017, at 1:55 PM, Michael Chiu via swift-server-dev
<</font><a href="mailto:swift-server-dev@swift.org"><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3>>
wrote:</font>
<br>
<br>
<br><font size=3>On Mar 27, 2017, at 5:13 AM, Logan Wright via swift-server-dev
<</font><a href="mailto:swift-server-dev@swift.org"><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3>>
wrote:<br>
If people feel extremely strong that there needs to be a concrete type,
then I'd like to push for reference type as much as possible. As far as
reference vs value type, I haven't really heard an argument for value types
beyond what feels like a reaction to value types being the hip new hotness.
While yes, they're great in Swift, and there's tons of places that should
absolutely be modeled with value semantics, a request/response interaction
represents a single request and should definitely be a reference based
interaction.</font>
<br><font size=3><br>
I disagree with this one. First of all I think most of the framework pass
the request and response as inout argument, if that is the case there shouldn’t
be much copy overhead in the run loop. Second the problem of reference
type is that everywhere the request and response exists could possibly
mutate the res/req, and it affect globally. It is true that in normal use
there shouldn’t be two place simultaneously operate on the same request
but that could happen. (Therefore protocol is the best isn’t it)<br>
</font>
<br><font size=3>In practice, we went through several model iterations
and the value type created very high levels of bugs and confusion for end
users. The three biggest problems we had were as follows:<br>
<br>
- Greatly increased bug levels and confusion related to unexpected mutation<br>
- Unnecessary code requirements added to every single passive access (ie:
middleware) increasing code bloat unnecessarily<br>
- Extreme performance loss due to massive copy overhead<br>
<br>
Each of these problems evaporated pretty instantaneously when moving to
reference types; it made it significantly easier to reason about for end
users. </font>
<br><font size=3>Just for curiosity, I’m very interested in the unexpected
mutation of value semantic, I have always had an impression of value semantic
are more free from unexpected mutation. <br>
</font>
<br><font size=3>Would like to remind again for those that skipped above
reading that our goal is not to build a web framework here, but rather
to build small tools that make building frameworks slightly easier for
library maintainers and creators. </font>
<br><font size=3>That’s so true lol.<br>
<br>
Michael.<br>
<br>
_______________________________________________<br>
swift-server-dev mailing list</font><font size=3 color=blue><u><br>
</u></font><a href="mailto:swift-server-dev@swift.org"><font size=3 color=blue><u>swift-server-dev@swift.org</u></font></a><font size=3><br>
</font><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><font size=3>https://lists.swift.org/mailman/listinfo/swift-server-dev</font></a>
<br><tt><font size=2>_______________________________________________<br>
swift-server-dev mailing list<br>
swift-server-dev@swift.org<br>
</font></tt><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev"><tt><font size=2>https://lists.swift.org/mailman/listinfo/swift-server-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br><font size=2 face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>