Re: StringBuilder Extension: IsQuotedBy

object-allocation in general on the .NET platform is really-really fast BUT if you do it in a tight parse-loop then it is expensive, i think that Sébastien's example with a 500nS loop is proof enough that object allocation may hurt performance.

Please remeber that, in my first post, I clearly stated that the choice (regex vs hand-coded) depended on the develment task, sadly a lot people didn't notice this and therefore a lot of post are slightly or completely of topic. (Comparing object allocation in tight parse-loops isn't even comparable to building entity objects from database queries; in the later case the object allocation speed is barely noticable)

FB: yes the initial size of the StringBuilder ctor prevents mem-fragmentation BUT allocating the right ammount from the start never hurts performance, you save a lot of "memcpy" operations due to the reduced need to grow the internal buffer.

Call-perf: even though the differences are barely measurable there are performance differences between the different call-types, here they are ordered fastest to slowest.

1. static, static calls are faster for a simple reason; you don't need to push the "this" vairable onto the stack
2. instance, normal instance calls are almost as fast as static calls but they have the "this" overhead
3. delegate and virtual, they are slightly slower since they are indirect.
In most cases the selected method doesn't impact performance but when you really-really need that extra bit of perf you have to understand the implications of the different call-types.

regards,
  Daniel

________________________________________
From: Discussion of development on the .NET platform using any managed              language [[email protected]] On Behalf Of Frans Bouma [[email protected]]
Sent: Friday, February 15, 2008 8:43 AM
To: [email protected]
Subject: Re: [DOTNET-CLR] StringBuilder Extension: IsQuotedBy

> You may say, this is for edge cases. Yes and no ... If object
> allocation was free, there would be no StringBuilder in the first
> place and it would not have a constructor asking for its initial size,
> etc.

        That initial size is to prevent memory fragmentation during memcpy
actions when the buffer needs to be resized. I don't see a relevance with
object creation speed and that parameter. I think the main reason the string
builder is there is to avoid having lots of objects to collect. I file that
kind of action under 'object destruction', not 'creation', though if you see
that as one action (as creating an object means it also has to be collected at
some point), you have a point.

                FB

>
> Sébastien
>
> On 2/14/08, Per Bolmstedt <[email protected]> wrote:
> > On Thu, 14 Feb 2008 11:42:01 -0500, =?ISO-8859-1?Q?S=E9bastien_Lorion?=
> >
> > <[email protected]> wrote:
> >
> >
> > > Allocating objects in a tight loop or methods like GetHashCode()
> >  > is still a big nono ...
> >
> >
> > Why? See Chris' recent post, for example. Repeating the mantra isn't
really
> >  helping. =]
> >
> >
> >  ===================================
> >  This list is hosted by DevelopMentor(R)  http://www.develop.com
> >
> >  View archives and manage your subscription(s) at
http://discuss.develop.com
> >
>
>
> --
> Sébastien
> www.sebastienlorion.com
>
> ===================================
> This list is hosted by DevelopMentor®  http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com