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

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