locked
Marshal.StringToHGlobalAnsi slow in 4.0!! RRS feed

  • Question

  • StringToHGlobalAnsi is about twice as slow in 4.0 as it was in 3.5.  it appears that the underlying call to Win32Native.CopyMemoryAnsi takes a StringBuilder as a parameter now rather than a pointer.

    is there another technique for string conversion we should be using?

    Brian Franzen
    Friday, March 12, 2010 10:54 PM

Answers

  • Hello Brian,

    Currently we don't plan to fix this in final 4.0 release (according to our assessment it has low impact on .NET users and there is a workaround for those who really care about this).
    Unless we will see more customers hitting this problem, it is also unlikely that we will release a hotfix for this.
    The bug will be fixed for next major release of CLR (the developer owning this area has already created a tracking bug for it).
    It is unfortunate, but that is the result of standard risk-benefit balance.
    If you disagree with this assesment, feel free to file a new bug on Microsoft Connect. In that case, please describe more details about your application, why this performance is important for you and why you think that the suggested workaround is not sufficient.

    Workaround:
    I was suggesting to copy out the 3.5 code into your own method/class and use that in your .NET 4 application. Would that be sufficient for you?

    Thanks,
    -Karel Zikmund,
    Developer on CLR team

    Monday, March 15, 2010 8:24 PM
    Moderator

All replies

  • Did you measure it as micro benchmark which avoids JITting time, etc.? (e.g. using MeasureIt)
    Can you please post your micro benchmark code here together with measurement data you got? (So we can verify it and investigate.)

    Thanks,
    -Karel
    Friday, March 12, 2010 11:25 PM
    Moderator
  • After chat with our interop expert it looks like a perf bug in CLR code.
    As a workaround for this perf regression you can use the code from 3.5 in your app. Is that acceptable solution for you in 4.0?

    -Karel

    Saturday, March 13, 2010 12:21 AM
    Moderator
  • Thank you for the response.
    Is this going to be corrected before release or in a hotfix?
    How are you suggesting that I bind to the older code?

    Brian Franzen
    Monday, March 15, 2010 7:04 PM
  • Hello Brian,

    Currently we don't plan to fix this in final 4.0 release (according to our assessment it has low impact on .NET users and there is a workaround for those who really care about this).
    Unless we will see more customers hitting this problem, it is also unlikely that we will release a hotfix for this.
    The bug will be fixed for next major release of CLR (the developer owning this area has already created a tracking bug for it).
    It is unfortunate, but that is the result of standard risk-benefit balance.
    If you disagree with this assesment, feel free to file a new bug on Microsoft Connect. In that case, please describe more details about your application, why this performance is important for you and why you think that the suggested workaround is not sufficient.

    Workaround:
    I was suggesting to copy out the 3.5 code into your own method/class and use that in your .NET 4 application. Would that be sufficient for you?

    Thanks,
    -Karel Zikmund,
    Developer on CLR team

    Monday, March 15, 2010 8:24 PM
    Moderator
  • Well Karel,
    Thank you for quick and thorough responses.  
    We will implement this routine ourselves and replace it.
    I'll also open a bug on MC.

    Thanks again
    Brian

    Brian Franzen
    Tuesday, March 16, 2010 4:22 PM
  • Please post link to the Connect bug here once you file it and put link to this thread also into the Connect bug.

    Thanks,
    -Karel

    Tuesday, March 16, 2010 6:31 PM
    Moderator