I'm concerned about the logging case for large maps. I propose just increasing the threshold to something practically high, but low enough that performance is predictable.
On Thu, Feb 16, 2017, 6:55 AM Tallak Tveide <tal...@tveide.net> wrote: > 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/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-co...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/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 > <https://groups.google.com/d/msgid/elixir-lang-core/CAHfREDXUsLtBSyuw0OunChCCY3bFPdufzqwbSgBF%2BD9pqaoo6w%40mail.gmail.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/CAOMhEnxQajyNp9-XX4P5%3D7Eu5VA_CGSWZ1SHzGVSH9gH6vin5g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
