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.parpail...@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.
> > > >
> > > > 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/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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/dc28924d-7a0a-4cab-9afb-c2b7b824d7cf%40Spark.
For more options, visit https://groups.google.com/d/optout.

Reply via email to