Again for the 3rd time, we're not talking about sorting the maps to store them; we're talking about sorting the maps when they're displayed for inspection. The main use case for inspection is debugging.
We are also talking about the _default_ way of displaying large (more than 32 entries) maps for inspection. Solely for inspection. Besides that, we already have a Map.sort/1. It's called Enum.sort/1. On Thu, Feb 16, 2017 at 8:13 AM, Jean Parpaillon <jean.parpail...@gmail.com> wrote: > 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. > -- Onorio Catenacci http://onor.io http://www.google.com/+OnorioCatenacci -- 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/CAP%3DvNq8Cs59yiOaMGf2OZ14G7BHLELTLjrEEda%3DGTCZENyQ8Ew%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
