BSTR caching

[Markus Stockhausen]

Hi,

the last week I took some time to implement the first try of BSTR
caching in oleaut.c. On the one hand this will fix a bug, on the other
hand Wine could save some CPU cycles and can catch up with the speed of
the native implementation. 

Attached you will find the result of my considerations. It is not yet
ready for implementation but will reflect the "big picture" I thought
of. I would be happy to receive some feedback on this work especially
the following questions are still open:

- Is DllMain the right location for Initialization/Cleanup
- I'm totally confused about the task of how to write a testcase
  for this change.

Thanks for your help.

Markus

[Henri Verbeet]

2009/10/8 Markus Stockhausen <markus.stockhausen(a)collogia.de>:
> Hi,
>
> the last week I took some time to implement the first try of BSTR
> caching in oleaut.c. On the one hand this will fix a bug, on the other
> hand Wine could save some CPU cycles and can catch up with the speed of
> the native implementation.
>
> Attached you will find the result of my considerations. It is not yet
> ready for implementation but will reflect the "big picture" I thought
> of. I would be happy to receive some feedback on this work especially
> the following questions are still open:
>
> - Is DllMain the right location for Initialization/Cleanup
> - I'm totally confused about the task of how to write a testcase
>  for this change.

I'm not sure about the exact details of what this should fix, but
wouldn't using a private heap have mostly the same effect?

[Markus Stockhausen]

> I'm not sure about the exact details of what this should fix, but
> wouldn't using a private heap have mostly the same effect?

Hi Henri,

it will definitely fix bug 12460 (self tested) and maybe 3756 as it
implements deferred release of BSTR memory. It does not matter if we are
using private heap or global heap. Important is, that the allocated
memory constantly survives a SysFreeString call until the next
SysAllocString call ist started. 

Related information:
http://www.winehq.org/pipermail/wine-devel/2009-October/078957.html
http://bugs.winehq.org/show_bug.cgi?id=3756

Additionally it reduces the time for Dealloc/Alloc Cycles of BSTR memory
in best cases by about 50%. 

Best regards.

Markus

[Nikolay Sivov]

Markus Stockhausen wrote:
> Hi,
>
> the last week I took some time to implement the first try of BSTR
> caching in oleaut.c. On the one hand this will fix a bug, on the other
> hand Wine could save some CPU cycles and can catch up with the speed of
> the native implementation.
>
> + *  Windows standard behaviour is something like this: Keep 3 freelists of
> + *  about 6-8 entries. One is for memory areas less than 32 bytes, the second
> + *  is for areas between 32 and 64 bytes and the third is for strings larger
> + *  than 64 bytes. Memory is allocated with length aligned to 16 bytes
> How did you guess this? Is it document somewhere?

[Markus Stockhausen]

Am Donnerstag, den 08.10.2009, 18:26 +0400 schrieb Nikolay Sivov:
> Markus Stockhausen wrote:
> > Hi,
> >
> > the last week I took some time to implement the first try of BSTR
> > caching in oleaut.c. On the one hand this will fix a bug, on the other
> > hand Wine could save some CPU cycles and can catch up with the speed of
> > the native implementation.
> >
> > + *  Windows standard behaviour is something like this: Keep 3 freelists of
> > + *  about 6-8 entries. One is for memory areas less than 32 bytes, the second
> > + *  is for areas between 32 and 64 bytes and the third is for strings larger
> > + *  than 64 bytes. Memory is allocated with length aligned to 16 bytes
> > How did you guess this? Is it document somewhere?

No,

only the result of solving bug 12460, debugging & a few testcases that
produce IMalloc log entries and in this way indirectly reflect the
behaviour of native oleaut (at least XP version).

Markus

[Alexandre Julliard]

Markus Stockhausen <markus.stockhausen(a)collogia.de> writes:
> only the result of solving bug 12460, debugging & a few testcases that
> produce IMalloc log entries and in this way indirectly reflect the
> behaviour of native oleaut (at least XP version).

You should not be looking at the internal behavior of native, only at
the external behavior as observed through test cases.

-- 
Alexandre Julliard
julliard(a)winehq.org

[Markus Stockhausen]

> You should not be looking at the internal behavior of native, only at
> the external behavior as observed through test cases.

Hm, 

I know, that 

testcase 
-> windows oleaut 
  -> wine ifs.c IMalloc logging 

is quite strange testing. Sadly this was the only way to explore the
reason for not freeing memory. I admit that the application is buggy in
this case but the intention was to get some more programs running.

Best regards.