(jiff v0.2.18)

Some functions, such as Zoned::add(self) and Zoned::add_assign(&mut self) are expressed in terms of Zoned::add(&self). The later necessarily requires the creation of a new Zoned object, followed by the drop of the old self (either by assignment, or by returning from the function).

In particular, this means that the original TimeZone must be cloned/copied first (for the new Zoned), then dropped. In the case of ARC_TZIF or ARC_POSIX, this involves a relatively costly atomic operations (e.g. #271). According to a flamegraph, in my case it accounted for half the cost of the add():

(in fushia are the entries containing the word)

Disclaimer: my test was running in a highly artificial scenario, with lots of threads, on lots of CPU cores, mostly doing Zoned::adds, so I suspect a lot of the cost is due to contention/synchronization on the Arc's atomic counter rather than the pure arithmetic on it.
Still, since the old TimeZone will not be used anymore, it shouldn't be necessary to clone the TimeZone and instead it could be moved.

In other words, it would be better if add(&self) was expressed in terms of add(self) (i.e. self.clone().add(...)), instead of the other way around.