.net memory checks

  • Thread starter Thread starter Kaniga
  • Start date Start date
K

Kaniga

I've been trying to figure this one out:
The CLR is said to do memory checks on memory access,
such as access to arrays and type-safety checks.
Now does this mean that every action of this sort would require a
memory check.
i.e.
if we are accessing an array, then in addition to the memory access,
we'll incur a performance hit of a memory check that sees to it that we
didn't go out-of-bounds.

This seems as if this would cause our application to do these kind of
checks so frequently that our performance would generally degrade
(accessing an array 1000 times would cause this check 1000 times) as
apposed to a non-managed access.

Are these checks negligible and doesn't affect performance ?
or maybe I'm missing something ?!
 
Kaniga said:
I've been trying to figure this one out:
The CLR is said to do memory checks on memory access,
such as access to arrays and type-safety checks.
Now does this mean that every action of this sort would require a
memory check.
i.e.
if we are accessing an array, then in addition to the memory access,
we'll incur a performance hit of a memory check that sees to it that we
didn't go out-of-bounds.

This seems as if this would cause our application to do these kind of
checks so frequently that our performance would generally degrade
(accessing an array 1000 times would cause this check 1000 times) as
apposed to a non-managed access.

Are these checks negligible and doesn't affect performance ?
or maybe I'm missing something ?!

In many cases, the array access can be verified by the JIT to not go
out of bounds, so the access doesn't need to be checked. For instance:

for (int i=0; i < array.Length; i++)
{
Console.WriteLine (array);
}

in C#. Note that this relies on arrays going from 0 to (length-1) which
isn't true for all arrays. I assume the JIT checks this once, or some
such clever mechanism.
 
ok, this is the "classic" way of accessing an array.
but suppose I do something more complicated such as:
- using an outer function that does the iteration, or
- i run a big loop which randomly picks an array element by index.

i guess that in these kinds of scenarios there is no escaping a check
on every access and a performance hit will incur.

is this correct ? and if so, how noticable is this overhead ?

Thanx,
Kaniga.
 
Kaniga said:
ok, this is the "classic" way of accessing an array.
but suppose I do something more complicated such as:
- using an outer function that does the iteration, or
- i run a big loop which randomly picks an array element by index.

i guess that in these kinds of scenarios there is no escaping a check
on every access and a performance hit will incur.
Yes.

is this correct ? and if so, how noticable is this overhead ?

I don't know how noticeable the overhead is, but it's never been an
issue in my work. In my experience, most applications aren't processor
bound, or if they are it's due to poor design (doing more work than is
required at a macro level) rather than this kind of thing.

I wouldn't let it worry you unduly.
 
Kaniga said:
ok, this is the "classic" way of accessing an array.
but suppose I do something more complicated such as:
- using an outer function that does the iteration, or
- i run a big loop which randomly picks an array element by index.

i guess that in these kinds of scenarios there is no escaping a check
on every access and a performance hit will incur.

is this correct ? and if so, how noticable is this overhead ?
a couple of CPU instruction?
like that:
if(i<0 || i>a.Length)
throw new ArrayOutOfBoundsException();

Calling a function would be much more CPU greedy than this bound check
(therefore it would go unnoticed).
On the other hand, if all you do in the loop is doing some computation with
say, 3 to 7 operation, the cost of the bound check would significally count
in the total time (maybe as high as 10%)
 
Kaniga said:
I've been trying to figure this one out:
The CLR is said to do memory checks on memory access,
such as access to arrays and type-safety checks.
Now does this mean that every action of this sort would require a
memory check.
i.e.
if we are accessing an array, then in addition to the memory access,
we'll incur a performance hit of a memory check that sees to it that we
didn't go out-of-bounds.

This seems as if this would cause our application to do these kind of
checks so frequently that our performance would generally degrade
(accessing an array 1000 times would cause this check 1000 times) as
apposed to a non-managed access.

Are these checks negligible and doesn't affect performance ?
or maybe I'm missing something ?!

The JIT compiler generates out-of-bound checks for every array access, there
is no way to prevent this unless you use pointers in unsafe construct.

Willy.
 
Back
Top