Front page | perl.perl5.porters |
Postings from February 2022
On Thu, 24 Feb 2022 at 09:19, Christian Walde <walde.christian@gmail.com> wrote: > On Thu, 24 Feb 2022 05:40:05 +0100, demerphq <demerphq@gmail.com> wrote: > > hysterical > > > Very bad form and meaningless character assassination regardless of what > one thinks about the technical subject. > Even though I think it is inappropriate to criticize my choice of a single word without including the context that it was used in, I apologize for using it anyway. What word would you have me use for a position that I feel is not rooted in any strong technical basis but is essentially a matter of personal preference unfounded by secondary policy objectives? The evidence is we *can* modify strings in place, and we know it is more efficient to do so, so eschewing doing so is purely a matter of personal preference. We are not a language like Java which chooses to accept the performance penalty of immutable strings for specific secondary objectives , eg Java has immutable strings because it makes implementing their thread model simpler (or perhaps even "possible"), at the cost of using much more memory for string operations. Our threads do not share buffers at all and copy data when initiating a thread, so why would we impose the downsides of immutable strings without any benefit? Our use of in place modifications allows us to operate on very large strings without incurring huge overheads. Chopping a 4GB buffer does not result in us using 8GB. Trimming a buffer with 4GB of text without inplace modification WOULD result in using 8GB. What technical reason is there for us to pay that penalty? cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next