Remove unnecessary constant_time_size

[ecatmur]

http::basic_fields::set_t::size() is unused core::multi_buffer::list_type::size() is only compared to 1 (in shrink_to_fit()); compare iterators instead.

[vinniefalco]

Are there any benchmarks?

[cppalliance-bot]

Timeline tracing charts: https://2504.beast.tracing.cppalliance.org/index.html

[codecov[bot]]

Codecov Report

Merging #2504 (4319bff) into develop (76043de) will decrease coverage by 0.00%. The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop    #2504      +/-   ##
===========================================
- Coverage    94.72%   94.71%   -0.01%     
===========================================
  Files          152      152              
  Lines        11868    11868              
===========================================
- Hits         11242    11241       -1     
- Misses         626      627       +1     

Impacted Files	Coverage Δ
include/boost/beast/core/multi_buffer.hpp	100.00% <ø> (ø)
include/boost/beast/http/fields.hpp	100.00% <ø> (ø)
include/boost/beast/core/impl/multi_buffer.hpp	97.59% <100.00%> (ø)
include/boost/beast/websocket/impl/ping.hpp	94.73% <0.00%> (-0.88%)	:arrow_down:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 76043de...4319bff. Read the comment docs.

[madmongo1]

@ecatmur Thank you for taking the time to post the PR. What do we gain in practice from this change? I am thinking in terms of memory use, search times, insertion times and so on.

[ecatmur]

Are there any benchmarks?

The only benchmark that is affected by this change is bench/buffers; I ran the benchmark (Ubuntu gcc 9, x86-64, release, threading-multi) but didn't observe any consistent differences in performance.

@ecatmur Thank you for taking the time to post the PR. What do we gain in practice from this change? I am thinking in terms of memory use, search times, insertion times and so on.

http::fields reduces from 88 to 80 bytes (x86-64). multi_buffer reduces from 72 to 64 bytes.

In terms of code size, multi_buffer::prepare() reduces from 1492 to 1378 bytes. There is no code change to fields test; gcc is smart enough to observe that the size field is never read, so entirely optimizes out stores to it.

As such, this change is unlikely to improve insertion times, at least for release builds with decent compilers. It's more of a cleanup exercise.

[vinniefalco]

hey, bytes are bytes :) they start adding up

[madmongo1]

I agree. I think we should accept this PR.

[klemens-morgenstern]

@madmongo1 @vinniefalco What's preventing this from getting merged?

[vinniefalco]

Merge it I guess. Note that in the new message model, the container is not node based anyway. It is just a string with the serialized message (plus a small table of offsets to allow random access).

[madmongo1]

I though I had merged it