I had this discussion with myself and decided not to post. The reason is that you actually have good control: if you want just bypass the inspect function and roll your own printing functions that are optimized.
My proposition earlier was just saying that, when sorting, if you discover many elements (say n > 1000), just don't sort and select the first few elements to inspect. I believe Elixir inspect will anyways not show all elements for large maps (i could be wrong here). My concern was more that you could for example connect to a production node to inspect the state, and if you had a huge map, it could affect runtime performance for the rest of the system unexpectedly. It's a corner case, as you probably wouldn't use a map for such large data collections but rather a database. So I'm still +1 with or without the optimization :-) 2017-02-16 14:13 GMT+01:00 Jean Parpaillon <jean.parpail...@gmail.com>: > Before usability and performance, there is control, because we are > speaking about a language, not a system. > > With a Map.sort/1 function, you can control the performance, with > automatic sorting you can not. > And with a Map.sort/1 function, you have usability. > > If you want out of control languages, just pick one over popular existing > ones: javascript, Pythom, Ruby... But please keep elixir clean ;) > > Jean > > Le jeudi 16 février 2017 14:07:33 UTC+1, Michał Muskała a écrit : >> >> Inspect is a way for providing debug information. Performance should be >> considered only after satisfying usability is provided. >> >> I'm +1 for the change. >> >> Michał. >> >> On 16 Feb 2017, 14:04 +0100, Jean Parpaillon <jean.pa...@gmail.com>, >> wrote: >> >> One of the most important reason when choosing a data structure over >> another is the cost of operations, if not, there is no interest in >> choosing, for instance, a Map over a Proplist. >> Of course there is a cost in sorting a map, and it is not insignificant. >> >> Why not just adding a Map.sort/1 function ? >> >> Jean >> >> >> Le jeudi 16 février 2017 12:54:43 UTC+1, Eric Meadows-Jönsson a écrit : >>> >>> 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.d...@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 <tal...@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-co...@googlegroups.com. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/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 >>>>> Fax: 512 857-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-co...@googlegroups.com. >>>> To view this discussion on the web visit https://groups.google.com/d/ms >>>> gid/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-co...@googlegroups.com. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/elixir-lang-core/3dbae292-3978-41d3-bb54-3b006d694260% >> 40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/3dbae292-3978-41d3-bb54-3b006d694260%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/elixir-lang-core/Lc2fWthKQSM/unsubscribe. > To unsubscribe from this group and all its topics, 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/84ad4498-7e76-4306-a925- > 83609bbaf128%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/84ad4498-7e76-4306-a925-83609bbaf128%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAHfREDXUsLtBSyuw0OunChCCY3bFPdufzqwbSgBF%2BD9pqaoo6w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
