parker89 commented on code in PR #929:
URL:
https://github.com/apache/httpcomponents-client/pull/929#discussion_r4472634059
##########
httpclient5/src/main/java/org/apache/hc/client5/http/impl/RequestSupport.java:
##########
@@ -93,8 +95,45 @@ static List<String> optimizePathSegments(final List<String>
inputSegments) {
}
}
+ /**
+ * @since 5.7
+ */
+ public static Supplier<String> pathPrefixSupplier(final String path) {
+ return new Supplier<String>() {
+
+ private final AtomicReference<String> cached = new
AtomicReference<>();
Review Comment:
Since this isn't meant to be shared across threads, could the cached value
live in a `volatile String` field on the supplier instead of a separate
`AtomicReference`? I measured `ProtocolExec.execute` end to end (JMH, JDK 25,
canned 200 response). The supplier plus `AtomicReference` adds 40 B per
request, and the JIT doesn't remove it. A volatile field brings that down to 24
B. A race would only compute the same value twice.
| Path, no AuthCache | before | this PR | volatile field |
|---|---:|---:|---:|
| `/` | 80 B | 120 B | 104 B |
| `/foo/bar` | 128 B | 120 B | 104 B |
| `/api/v1/items/12345?a=1&b=2` | 200 B | 120 B | 104 B |
It's still a net win for most paths. Short ones like `/` already returned
the input string without allocating, so they come out slightly behind either
way.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
