If each object exists independently - which it does in this case - you must use
a free on each object. So you are going to loop - it just may be hidden from
you.
The idea was to avoid all free calls and terminate the process instead - which
I pointed out has been a solution for quite a long time.
> On Feb 14, 2020, at 8:35 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
>
>
>> On Friday, February 14, 2020 at 3:32:54 AM UTC+1, robert engels wrote:
>> You can clearly see that the vast majority of CPU time was consumed by
>> allocation and de-allocation.
>
> In the case of this particular benchmark, it is pointless to be pointing out
> the cost of individual malloc+free calls because the memory is being
> deallocated in a for-loop:
>
> for(o in object-list) { delete o; }
>
> and it is probable that most experienced C++ programmers would during
> optimization convert this for-loop to use delete[] or use std::vector to hold
> the objects.
> --
> 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/68217d56-e01d-4046-8f25-b773cf38afbb%40googlegroups.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/43F0D090-D6B5-4840-AAE2-D82A189D4D91%40ix.netcom.com.
