Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Michael S Newsgroups: comp.lang.c Subject: Re: realloc() - frequency, conditions, or experiences about relocation? Date: Mon, 17 Jun 2024 20:20:57 +0300 Organization: A noiseless patient Spider Lines: 30 Message-ID: <20240617202057.000001a2@yahoo.com> References: <3PZbO.32803$Kxzd.19726@fx15.iad> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Date: Mon, 17 Jun 2024 19:20:40 +0200 (CEST) Injection-Info: dont-email.me; posting-host="21c0d5cac32843964269a269a3ca89e9"; logging-data="607686"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/CEuwtSPRezCEzXKVecOH4AUbxt33hI/E=" Cancel-Lock: sha1:/mvWFAxutm96jFpyloNuDudqGNs= X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32) Bytes: 2432 On Mon, 17 Jun 2024 16:50:07 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Janis Papanagnou writes: > >In a recent thread realloc() was a substantial part of the > >discussion. "Occasionally" the increased data storage will be > >relocated along with the previously stored data. On huge data sets > >that might be a performance factor. Is there any experience or are > >there any concrete factors about the conditions when this relocation > >happens? - I could imagine that it's no issue as long as you're in > >some kB buffer range, but if, say, we're using realloc() to > >substantially increase buffers often it might be an issue to > >consider. It would be good to get some feeling about that internal. > > I've not found a use for realloc in the last forty five years, myself. > Did you find use for std::vector:resize()? If yes, that could be major reason behind not finding use for realloc(). Another possible reason is coding for environments where dynamic allocation either not used at all or used only during start up. At least for me those are major reasons why I very rarely used realloc since beginning of programming as a pro. > I suspect that the performance issues are not an issue for relatively > small datasets, and are often exhibited during the non-performance > critical 'setup' phase of an algorithm.