Profiling shows that almost all of the time in evaluating the last expression is in calculating the hash of value pv10k, which is because the hash calculation is not cached as it is for most other collections. There is a TBD in the implementation mentioning this.
Attached file clj-2528-hash-caching-primitive-vecs-v1.patch contains a proposed patch to implement hash caching for primitive vectors. The new field names are __hashx and __hasheqx instead of __hash and __hasheq, because __hash and __hasheq are reserved names for all deftype declarations. I understand why that is so for defrecord, but not so clear why those names are reserved for deftype.
Attached file clj-2528-hash-caching-primitive-vecs-v2.patch is the same as the earlier one, except it uses hash and hasheq as the names of the type int fields to store the cached hash values. Confirmed that they are Java private fields, so the fact that hasheq has the same name as the public hasheq method should not present any issues.