Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| Message-ID | <6b3ogc-uob.ln1@wilbur.25thandClement.com> (permalink) |
|---|---|
| From | <william@wilbur.25thandClement.com> |
| Subject | Re: Memory and error management approaches |
| Newsgroups | comp.lang.c |
| References | (2 earlier) <n17app$82n$1@speranza.aioe.org> <d9opetF6ovuU6@mid.individual.net> <n17cgd$cf2$1@speranza.aioe.org> <d9q0hqF7v31U2@mid.individual.net> <n18kna$jnt$1@speranza.aioe.org> |
| Date | 2015-11-03 17:24 -0800 |
Morten W. Petersen <morphex@gmail.com> wrote: > On 02.11.2015 21:48, Ian Collins wrote: >> Morten W. Petersen wrote: > [...] >>> Well, the error structure will contain pointers and be maybe 20 pointers >>> big, and these pointers will in turn be linked lists if there is more >>> than one entry.. >>> >>> If all dynamically allocated memory is freed and streams are closed on a >>> longjmp, what's the problem? >> >> You have introduced a laborious, manual and therefore error prone >> overhead to each resource allocation and release. >> >> There are good reasons why no attempt at bolting on an exception >> mechanism on to C has ever caught on. > [...] >>>> Trying to add such micro-optimisations on modern CPUs is seldom worth >>>> the effort. >>> >>> Well that would depend on the data type and size wouldn't it? >> >> The time to look at custom allocation is after extensive testing and >> profiling shows a bottleneck with dynamic memory. > > The reason I'm asking about custom allocation is that if I do some > custom memory allocation, it isn't a big deal to also setup info > that can be used on setjmp/longjmp tear-downs. > > A bit of what I've seen online is that memory allocators have speed > benefits.. IMO, the best reason to use a custom allocation scheme is to improve the quality of your code, not the performance. By improving the quality I mean improving readability, permitting simplifications, etc. But event that's a trade-off. See, e.g., OpenBSD's take on the OpenSSL Heartbleed fiasco, where they claim the biggest sin was that by using a custom allocator OpenSSL circumvented the sophisticated attack mitigations in OpenBSD's system allocator. > > Also, seeing this: > > http://www.pjsip.org/pjlib/docs/html/group__PJ__POOL__GROUP.htm A few criticisms: 1) The more sophisticated the allocator, the more complex it is. Ultimately you're just substituting one general purpose allocator for another. Modern system allocators already implement pools and other strategies. They're not all buddy allocators. 2) Debugging is usually much easier when dealing with the system allocator. For any debugging feature claimed by the library author, the capability and tooling for the system allocator will be even better, _especially_ on systems like Solaris, Linux, and OS X. (I can't speak for Window's CRT.) 3) Adding third-party dependencies, especially for mundane stuff like memory management, can become a maintanence headache, and possibly a source of frustration for users. 4) Custom allocators--for improving performance or code quality--are best when targeted at specific parts of your application. E.g. using a simple object stack/bump allocator for a parser, or a slab allocator for object construction. In these situations, the implementation is often trivial, and can provide benefits beyond what more general libraries offer. By looking at third-party libraries, you're already conceding that your approach is not focused on your immediate problems. > I can use a memory pool, and destroy it after a longjmp and memory > has been handled. Sure. I use that approach quite often. I've also used longjmp for error handling. But I only use these techniques in particular subcomponents, where the cost+benefit is maximized, and the implementation doesn't leak outside the interface. In terms of APIs, including internal APIs, you're almost always better off sticking to the system facilities, as you would most other languages. More importantly, sticking to tried-and-true patterns (e.g. RAII[1]) is far and away the most critical choice you can make. Obsessing over memory allocation is one of the favorite pastimes of C newbies (and, unfortunately, even some longtime C programmers), alongside dreaming of ways to abuse pointers and type punning. Certainly I went through that phase, and years later am still dealing with the costs. [1] RAII as a discipline works just as well in C as in C++. Despite lacking automatic destructors, the absolute benefit might be even greater in C because memory management can be more burdensome, or at least verbose.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 10:17 +0100
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-02 22:25 +1300
Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 10:36 +0100
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-02 22:41 +1300
Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 11:05 +0100
Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 12:15 +0000
Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 20:31 +0100
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 09:48 +1300
Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 13:17 -0800
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 10:29 +1300
Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 13:48 -0800
Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 22:31 +0100
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 11:02 +1300
Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 15:21 -0800
Re: Memory and error management approaches <william@wilbur.25thandClement.com> - 2015-11-03 17:24 -0800
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-04 14:38 +1300
Re: Memory and error management approaches <william@wilbur.25thandClement.com> - 2015-11-04 10:48 -0800
Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-04 11:28 -0800
Re: Memory and error management approaches James Kuyper <jameskuyper@verizon.net> - 2015-11-04 14:54 -0500
Re: Memory and error management approaches Gareth Owen <gwowen@gmail.com> - 2015-11-06 07:50 +0000
Re: Memory and error management approaches <william@wilbur.25thandClement.com> - 2015-11-06 11:40 -0800
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-07 09:38 +1300
Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-06 20:55 +0000
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 02:23 -0800
Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-07 11:29 +0000
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 04:18 -0800
Re: Memory and error management approaches asetofsymbols@gmail.com - 2015-11-07 05:41 -0800
Re: Memory and error management approaches asetofsymbols@gmail.com - 2015-11-07 06:27 -0800
Re: Memory and error management approaches Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2015-11-07 18:20 +0100
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 10:28 -0800
Re: Memory and error management approaches gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-07 19:01 +0000
Re: Memory and error management approaches raltbos@xs4all.nl (Richard Bos) - 2015-11-10 16:14 +0000
Re: Memory and error management approaches Gareth Owen <gwowen@gmail.com> - 2015-11-10 21:13 +0000
Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-10 19:26 +0000
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-03 18:25 -0800
Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-06 10:05 +0100
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 02:15 -0800
Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 12:01 +0000
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 06:05 -0800
Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 17:18 +0000
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 09:27 -0800
Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 23:02 +0000
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 12:07 +1300
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 15:23 -0800
Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 10:28 -0800
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 09:34 +1300
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 14:05 -0800
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 11:27 +1300
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-03 18:15 -0800
csiph-web