AW: AW: Octstr functions do too many allocations

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.

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).


-----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