Re: C# coding guidelines: use "this." or not when referring to member fields/properties within the object?

Tech-Archive recommends: Fix windows errors by optimizing your registry

"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message
news:MPG.1eb5e70cf5c808d98d13f@xxxxxxxxxxxxxxxxxxxxxxx
What makes you think that reordering affects performance though? Have
you measured it (in C#, not VB6)?

It has to do a comparison to each value presumably starting at the top.
Putting a commonly used item towards the bottom should result in more
comparisons.

I *think* there's a way you can avoid it, but I can't remember it.

You could use the DebuggerStepThroughAttribute.

If you think you won't want to step into those properties in general, I
believe there's an attribute you can apply to stop the debugger from
doing it. I'm blowed if I can find the name of it though :(

It used to be applied to the designer generated code in InitializeComponent
I believe but doesn't look like it is anymore.

Well, using the Length property is minisculy faster in C#/.NET too -
but personally I would still use if (x=="") because I find that easier
to read. Others find the .Length property easier to read, so they use
that - it's fine.

I don't think there's much difference in readability myself so use the
faster.

Now, people will use #1 because they think it makes it faster to only
look at the Count property once. In fact, #2 is faster than #1 (I
believe) because the JIT is able to make use of that common pattern and
optimise away the bounds checks - at least in some situations. (It may
be for arrays but not lists - I honestly can't remember at the minute,
and it may well change between CLR versions.)

Interesting. I would have used #1 when I needed the index.

But do you go out of your way to make tiny changes to the code which
take it away from the path of clearest readability, just for the sake
of performance which is probably insignificant? How would you go about
iterating through a list in your normal code?

Generally I would use #3 but wouldn't think it was the end of the world if
#1 or #2 was used when #3 could have been. It's possible you are
"micro-optimising" readability if you are using things like (X=="") instead
of len because of readability. I wouldn't consider readability down to that
level.

Michael


.

Relevant Pages

  • Re: [PATCH] sysfs: kill an extra put in sysfs_create_link() failure path
    ... > faster for the common case -- not good enough for you?! ... Sorry, not agreed on readability. ... like that do matter but not that much. ... My taste might not be the best around ...
    (Linux-Kernel)
  • Re: Why all the variations in phonetics?
    ... Its use can enhance readability. ... Given Zanzibar isn't exactly a common word and probably hasn't been since ...
    (uk.radio.amateur)
  • Re: What should I Use ?
    ... I totally agree with what your saying and I also think readability is ... can predetermine approximate sizes for array based lists or a stringbuilder. ... initialise the stringbuilder with a length of myObjectColllection.Count*1024. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Idea to support public/private.
    ... Brian Allen Vanderburg II a écrit: ... lists (Does python follow its idea of readability or something like that) and I thought of a 'possible' way to add this support to the language. ...
    (comp.lang.python)