Re: AW: AW: Octstr functions do too many allocations

Memory pool is of course perfect: then you can write readable code with
lots of appends, without worrying about allocations. This would be 
another
gw_mem module, i suppose. But has someone time for this ?

Other problems (I did profiling with Apple's CHUD) are octstr_imm (5%
of time was used for locking!) and octstr_search. You can rewrite 
comparison
code, but better octstr_search would be really welcome.

Aarno

On 4.11.2003, at 14:38, Alexander Malysh wrote:

> On Tuesday 04 November 2003 14:19, Jörg Pommnitz wrote:
>> I'm not so sure. There are a lot of cases in the WAP/MMS stack
>> where data passes from one layer to the next and Kannel does
>> basically something like this:
>>
>>   WAPEvent *newevent = WAPEventCreate(something);
>>
>>   newevent->u.something.data = octstr_duplicate
>> (oldevent->u.somethingelse.data);
>>   dispatch (newevent);
>>   WAPEventDestroy (oldevent);
>>
>> As for the difficulty of using this: I don't see it. If you make
>> a mistake and share an octstr that needs to be modified, then an
>> assertion would be triggered immediately and the bug could easily
>> be fixed.
>
> It may have too many side effects and trigger too many panics (imo). 
> what's
> about implement something like apache's mem pool? So we can 
> preallocate mem
> and have no need to make syscalls any time. I know it's not a easy 
> task , but
> so _all_ modules will profit from it w/o any changes...
>
>>
>> Regards
>>   Joerg
>>
>> P.S.: While we are talking about optimizations: How about abandoning
>> the Kannel-principle: "Every container is a list" ? I suspect a lot
>> of cycles could be freed through the use of data structures that fit
>> the problem and that provide better search complexity than O(N).
>
> I'm ++1 for such changes! I have seen too many places that e.g hash 
> would be
> at least 2 times faster...
>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Alexander Malysh [mailto:[email protected]]
>> Gesendet: Dienstag, 4. November 2003 14:08
>> An: Jörg Pommnitz; [email protected]
>> Betreff: Re: AW: Octstr functions do too many allocations
>>
>> On Tuesday 04 November 2003 13:43, Jörg Pommnitz wrote:
>>> Something I suggested years ago are reference counted Octstr's.
>>> A lot of octstr_duplicate calls could easily become octstr_getref.
>>> In this case a reference count inside a octstr would go up.
>>>
>>> A reference count > 1 would make the octstr immutable and 
>>> octstr_destroy
>>> would decrease the reference count and do the actual releasing only
>>> if it drops to zero.
>>
>> hmm, good idea but doesn't work in most cases. We call 
>> octstr_duplicate in
>> most cases in order to not touch original octstr (e.g. manipuating of
>> duplicat). So it (imo) will be too hard/expensive to trace such 
>> things,
>> because we should "rewrite" whole octstr module...
>>
>>> Regards
>>>   Joerg
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Aarno Syvänen [mailto:[email protected]]
>>> Gesendet: Dienstag, 4. November 2003 11:43
>>> An: [email protected]
>>> Betreff: Octstr functions do too many allocations
>>>
>>>
>>> Hi List,
>>>
>>> If you use mmsc and ppg performance issues are actually relevant,
>>> because use have three protocol *suites* running in the machine.
>>> (In spite of the fact that smsc and the wireless network are slow,)
>>>
>>> Worst is octstr_append, used by compilers. Octstr_append_char
>>> actually allocates just two bytes ! (Every time it is called.)
>>>
>>> When compiling, we actually can make a guess how big the output
>>> is, because we have the input document. So we can allocate
>>> everything we need at the start.
>>
>> if we know while compiling, how long ocstr should be , then yes we 
>> should
>> do
>>
>> prealloc. How about this trick?
>>
>> Modify octstr_create_from_data_real to:
>>
>> Octstr *octstr_create_from_data_real(const char *data, long len, 
>> size_t
>> expected_size, const char *file,
>>                                      long line, const char *func)
>> Within function we just do:
>> octstr->size = expected_size;
>> gw_malloc(octstr_expected_size);
>>
>> So you can put expected size of octstr and no allocation will be 
>> processed
>> anymore and we have no need to modify/rewrite whole octstr module...
>>
>>> Some other ideas ?
>>>
>>> Aarno
>
> -- 
> Best regards / Mit besten Grüßen aus Düsseldorf
>
> Dipl.-Ing.
> Alexander Malysh
> ___________________________________________
>
> Centrium GmbH
> Vogelsanger Weg 80
> 40470 Düsseldorf
>
> Fon: +49 (0211) 74 84 51 80
> Fax: +49 (0211) 277 49 109
>
> email: [email protected]
> web: www.centrium.de
> msn: [email protected]
> icq: 98063111
> ___________________________________________
>
> Please avoid sending me Word, Excel or PowerPoint attachments.
> See http://www.fsf.org/philosophy/no-word-attachments.html
>
>