Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #74711

Re: Memory and error management approaches

From Ian Collins <ian-news@hotmail.com>
Newsgroups comp.lang.c
Subject Re: Memory and error management approaches
Date 2015-11-03 11:27 +1300
Message-ID <d9q69uF7v31U8@mid.individual.net> (permalink)
References <n179ne$64b$1@speranza.aioe.org> <d9ooh3F6ovuU4@mid.individual.net> <f49c768f-cfbd-4884-9b7b-5b51cf47c439@googlegroups.com> <d9pvmaF7v31U1@mid.individual.net> <84a6c016-5c6b-41e2-9d6b-68cf92ad0c32@googlegroups.com>

Show all headers | View raw


Malcolm McLean wrote:
> On Monday, November 2, 2015 at 8:34:32 PM UTC, Ian Collins wrote:
>> Malcolm McLean wrote:
>>> On Monday, November 2, 2015 at 9:26:06 AM UTC, Ian Collins wrote:
>>>> Morten W. Petersen wrote:
>>>>
>>>>> Any thoughts on this?  A while ago someone wrote on comp.lang.c about
>>>>> writing a custom memory manager for performance; is that something that
>>>>> could be coupled with all of this?
>>>>
>>>> Most of the platforms I'm familiar with provide specialised memory
>>>> allocator libraries, you shouldn't have to roll yet another one for
>>>> something as simple as XML parsing.
>>>>
>>> In an ideal world, that would be good advice. In the reality, it's
>>> bad advice.
>>
>> In this case, it is good advice.  How many straight forward (I'd include
>> XML parsing here) applications require a custom allocator?  Virtually
>> none.
>>
> The bad advice isn't to stick with malloc() until proved inadequate.
> It's to introduce a third party dependency with a ready-made special-
> purpose allocator.

I didn't suggest introducing a third party dependency.

You would choose the allocator based on how an application uses the 
parser library.  One application might use multiple threads to parse 
many documents in parallel, another might be parsing a single monster 
document.  The allocator requirements for these would be very different. 
  For the former you might want to consider an allocator optimised for 
threading and for the latter the standard allocator.  A decent platform 
will give you that choice.

-- 
Ian Collins

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


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