Yes! That always works at the application level. Write an “inspector” that examines things, duplicating and copying the live parts.
I do that in several of my long running math apps, where my pool of big.Ints end up with 50-100 thousand digit allocations in a big because of one giant multiply...I examine them as I recycle and manage this. Makes a big difference. But doing it when you know the situation is easy. It’s having the compiler “just know” that is so challenging. (Unless you box everything like Java...and that’s an expensive path) On Fri, Jul 19, 2019 at 12:43 PM Andrey Tcherepanov < xnow4fippy...@sneakemail.com> wrote: > My suggestion was not to make "the kitchen" work harder by marking parts > of the hamburger to be good for the consumption, no. My suggestion was to > recycle bitten hamburger out and put just the bitten piece aside in a doggy > bag, sorry. > > A. > > On Friday, July 19, 2019 at 1:08:51 PM UTC-6, Michael Jones wrote: >> >> There is a difference in the meanings of terms in this discussion, maybe >> that’s confusing to some. (That is, Ian went right to the heart of the >> matter but maybe a simpler fact needs to be made plain to others.) >> >> When you think of the memory used by a slice and of maybe using less of >> it and “returning” the rest, like putting uneaten food away for tomorrow, >> you’re making several big demands. >> >> You demand severabity, that half a TV set is a reasonable thing to >> discuss, like half a pie. In fact that backing array was created by the >> allocator as “256 bytes you can use, with other info you don’t know about >> somewhere.” To chop off half and “give it back” is not part of the >> contract. The contract is: use it until you’re done with it. (The whole TV, >> because of wires and glass bits). >> >> One alternative is to make 256 allocations of the small parts, then >> allocate an array as pointers to each little part. Then you can reshape the >> array and free the extra parts. This freedom pays a tax in many ways, and >> always pays it in the normal case. >> >> But in the efficient single group allocation style (Go, C, C++, ...) the >> desire to return part of a monolithic allocation is a major burden. Ian >> went right to the elements of that burden. But since the follow ups still >> wanted the burden I thought maybe a reminder of why it is hard would help. >> >> On Fri, Jul 19, 2019 at 7:36 AM Ian Lance Taylor <ia...@golang.org> >> wrote: >> >>> I'm not sure what to say. If someone wants to write up and work on a >>> detailed implementation proposal, that is fine. Go for it. As I said >>> earlier, I think it would be hard. I'll add that I don't think that >>> the difficulty would pay off in terms of the amount of real code that >>> it would help. There is a lot of other hard work that could be done >>> in the compiler that would, I think, help many more programs. >>> >>> Ian >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golan...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVvDz1kRzpoKNtw5MDH%2BrFpsW6fLSqrT%3DS83JGhM_Y-%2BA%40mail.gmail.com >>> . >>> >> -- >> >> *Michael T. jonesmichae...@gmail.com* >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/d371646c-1f7c-4df1-8077-14e40c25ae04%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/d371646c-1f7c-4df1-8077-14e40c25ae04%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CALoEmQy%3DRtfLzFqUnnzng-dba2mm0kx0o7hc2pTUDT_RTb1UpA%40mail.gmail.com.
