My guess is that the sorting time will be insignificant compared to sending
the data down your logging infrastructure regardless if it's just printing
to a terminal or if it's sending data over a socket. Both require syscalls
and IO which is usually the more time consuming part.
I think it's wrong to prioritize performance instead of usability for
Inspect since the functionality is made for humans. If performance actually
is more important than readability then there are lots of optimizations we
can do to Inspect, for example dropping algebra documents and pretty
On Wed, Feb 15, 2017 at 10:04 PM, Dmitry Belyaev <be.dmi...@gmail.com>
> If I dump a map to logs I don't care about its order, I only want it to be
> as fast as possible. Logging already introduces a serious performance hit,
> and sorting would make logging even more expensive performance wise.
> As was mentioned previously if a map is small it's already sorted. So it
> would be a waste of time although insignificant. But if it's huge it would
> spend both cpu and memory to vuild sorted structure, and later would spend
> more cpu on its garbage collection. I don't like the idea of losing
> production performance only for development convenience.
> On 16 February 2017 07:25:51 GMT+11:00, Bruce Tate <br...@rapidred.com>
>> Good points, but isn't inspecting a map generally a development time
>> activity? Especially big maps?
>> Sometimes, optimizing people is the right thing to do. When you're
>> looking at big lists of ecto objects and working to pick out an ID, having
>> things in order is a big deal.
>> On Wed, Feb 15, 2017 at 2:17 PM, Tallak Tveide <tall...@gmail.com> wrote:
>>> I believe it would be useful to not sort if there are very many keys as
>>> well. A huge map would presumably be inspected in a short while, skipping
>>> keys after the first few. Inspecting a huge map could become cpu/memory
>>> intensive, which I would find surprising... anyways +1 from me
>>> You received this message because you are subscribed to the Google
>>> Groups "elixir-lang-core" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to elixir-lang-core+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> For more options, visit https://groups.google.com/d/optout.
>> Bruce Tate
>> President, RapidRed, LLC
>> Phone: 512.772.4312 <(512)%20772-4312>
>> Fax: 512 857-0415 <(512)%20857-0415>
>> Author of Seven Languages in Seven Weeks, Deploying Rails Applications,
>> From Java to Ruby, Rails: Up and Running, Beyond Java, 6 others.
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.