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 printing. On Wed, Feb 15, 2017 at 10:04 PM, Dmitry Belyaev <be.dmi...@gmail.com> wrote: > 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> > wrote: >> >> 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. >> >> -bt >> >> 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 >>> gid/elixir-lang-core/8a1f314b-efdb-468d-8dae-ba6492aa0f95% >>> 40googlegroups.com. >>> 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/ > msgid/elixir-lang-core/2649817D-21D7-4C50-B477-7038486C9849%40gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/2649817D-21D7-4C50-B477-7038486C9849%40gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Eric Meadows-Jönsson -- 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/msgid/elixir-lang-core/CAM_eapgZEX8CfbjJ-pTxinL0fFEaknw50gTtJNLJMHDiq6RMSQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
