# Slow deserialization of booleans

**URL:** <https://discourse.julialang.org/t/slow-deserialization-of-booleans/129260>\
**Category:** Performance\
**Created:** [May 23, 2025, 1:43am UTC](https://discourse.julialang.org/t/slow-deserialization-of-booleans/129260 "2025-05-23T01:43:32Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [May 23, 2025, 3:25pm UTC](https://discourse.julialang.org/t/slow-deserialization-of-booleans/129260/6 "2025-05-23T15:25:29Z")

</div>

I stand corrected again, and it jogged my memory about something I learned just last week. Improving inference to `Array{Bool}` and any optimizations from knowing the only `setindex!` method does not eliminate the runtime dispatch, and that [contributes allocations](https://discourse.julialang.org/t/why-does-runtime-dispatch-allocate-when-the-return-type-is-inferred/129061/6) by boxing unboxed inputs or outputs, even when similar techniques improved type inference all the way to concrete types. Your code is actually doing fewer allocations than I’d expect, but I’m still terrible at predicting dispatch boxing. To save a click of the link, it’s hypothetically possible for runtime dispatch to not do that, but that’s not how it’s implemented right now and would require a significant change to Core Julia and the GC.

---

_[View the full topic](https://discourse.julialang.org/t/slow-deserialization-of-booleans/129260)._