```
julia> n = big"3"^100000;
julia> t = (n // 1, n, Rational{BigInt}(n));
julia> typeof(t)
Tuple{Rational{BigInt}, BigInt, Rational{BigInt}}
julia> map(Base.summarysize, t)
(19872, 19968, 20008)
julia> first(t) == last(t)
true
julia> n = big"3"^1000000;
julia> t = (n // 1, n, Rational{BigInt}(n));
julia> map(Base.summarysize, t)
(198184, 199272, 199312)
julia> first(t) == last(t)
true
julia> versioninfo()
Julia Version 1.9.0-DEV.1242
Commit 53bb7fb5df7 (2022-08-31 18:42 UTC)
Platform Info:
OS: Linux (x86_64-linux-gnu)
CPU: 8 × AMD Ryzen 3 5300U with Radeon Graphics
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-14.0.5 (ORCJIT, znver2)
Threads: 3 on 8 virtual cores
```

When I have a `BigInt`

, there’s two methods that come to mind for converting it into a rational:

- A direct invocation of the
`Rational`

constructor. This causes the summarysize compared to the original`BigInt`

to*increase*. - Creating a fraction with one as the denominator. This causes the summarysize to
*decrease*in my examples.

I wonder what could be the reason for the disparity. Something to do with GMP’s allocation strategies? What are the performance implications here?

EDIT: it definitely seems like creating a rational in the second way causes the size of the BigInt numerator to decrease, something which doesn’t happen if I just use `copy`

on the BigInt:

```
julia> n = big"3"^1000000;
julia> m = n//1;
julia> typeof(m.num)
BigInt
julia> typeof(m.den)
BigInt
julia> map(Base.summarysize, (n, m, m.num))
(199272, 198184, 198144)
```