IO.inspect already performs formatting and transformations while printing data. That is its purpose, to help present data for debugging during development.
Leaving inspect calls in production is already a performance problem, let alone inspecting maps with more than 32 entries. This would fix an unexpected inconsistency, I'm in favor of it. +1 from me. > On Feb 16, 2017, at 7:13 AM, Jean Parpaillon <[email protected]> > 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 <[email protected]>, 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected]> 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 [email protected]. >>>>>>> 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 [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/elixir-lang-core/2649817D-21D7-4C50-B477-7038486C9849%40gmail.com. >>>>> >>>>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/3dbae292-3978-41d3-bb54-3b006d694260%40googlegroups.com. >>> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/84ad4498-7e76-4306-a925-83609bbaf128%40googlegroups.com. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/E3BFEF00-7475-4716-8525-8B8BE1A4419B%40sorentwo.com. For more options, visit https://groups.google.com/d/optout.
