feat(proto): update to time 0.2

[koushiro]

No description provided.

[seanmonstar]

Thanks for the PR!

I wonder, how "weighty" is time v0.2? We really only need the ability to format a SystemTime to a single specific format...

[jhpratt]

I was looking to upgrade some more reverse dependencies, and hyper is among the most commonly used of them. I see this PR is open, so I may as well review it!

Sean — the overhead compared to 0.1 for this specific use case shouldn't be much, if any at all. I'm not familiar with hyper's internals, so I likely wouldn't be able to create an accurate benchmark. I think the only difference would be that this calculates the year, month, day, hour, minute, and second up-front as opposed to at formatting time. This does add a slight overhead in memory usage (56 bytes to 64) due to the presence of the stored UTC offset & additional padding. If you're careful, this could be worked around, which would bring the size back down to 56 bytes per my quick check. I'd only do that if it has noticeable performance improvements, though.

[jhpratt]

I'm by no means the maintainer of hyper, but I would imagine keeping this separate would be best.

[jhpratt]

Easier to just add the number of nanoseconds directly. It may be worth checking the optimized output of this, though, as the compiler may be able to optimize away the x - x.

Suggested change

	let nanosecond = self.next_update.time().nanosecond();
	self.next_update = now + Duration::seconds(1) - Duration::nanoseconds(nanosecond as i64);
	self.next_update = now + Duration::nanoseconds(1_000_000_000 - now.nanosecond() as i64);

[tomaka]

As someone who is experimenting with the wasm32-wasi target, time v0.1 is problematic because it does the time gathering itself. I have to use a local override of this crate at the moment to make things work.

time v0.2, on the other hand, delegates everything to std::time::SystemTime, which does work on wasi.

So if that's a valid argument, landing this PR would make hyper compile for Wasi.

[jhpratt]

While I don't believe it should block this PR landing, a 0.3 is in progress, which will have very different formatting. It's not done yet, so I can't speak as to how well the compiler will optimize it away, but it should be very low cost, assuming the format is known at compile-time (which it sounds like it is).

[seanmonstar]

I've filed #2253 to remove time 0.1. I was concerned about the "weight" of the new version of time, specifically it has an extra dependency, a procedural macro, and a bunch of time manipulation code that hyper didn't need. I've opted to use httpdate, which still uses SystemTime internally, but has much less code to compile.

[jhpratt]

Just to address the concern about additional weight, time 0.3 will have far more aggressive feature flags. The macros will be fully rewritten to be lightweight (eliminating syn and quote) and being a flag. I also recently ran cargo diet to eliminate publishing unnecessary files, though that's not yet published (or even pushed up I believe).

The extra dependency is standback, which compiles down to literally nothing on the most recent stable — its sole purpose is to backport APIs, so all the compiler would have to do it tokenize and determine what compiler is being used via a build script.

I've actually considered putting the arithmetic behind an on-by-default flag, such that no-default-features would essentially leave you with just the struct definitions and inherent methods, nothing else. Formatting will be placed behind a flag in 0.3 as well.

Of course, httpdate is still probably more efficient, given that it's a fixed format. It's pretty difficult to surpass that, I'd imagine. Just throwing this out there to indicate that most of the issues with regard to weight will be improved! Thanks for your work on hyper and everything else.

[seanmonstar]

That's excellent to hear!