By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,620 Members | 1,303 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,620 IT Pros & Developers. It's quick & easy.

ArrayList without Boxing and UnBoxing

P: n/a
How can I create an ArrayList in the older version of .NET that does not require
the expensive Boxing and UnBoxing operations?

In my case it will be an ArrayList of structures of ordinal types.

Thanks.
Nov 3 '06 #1
Share this Question
Share on Google+
94 Replies


P: n/a


"Peter Olcott" <No****@SeeScreen.comwrote in message
news:ho*******************@newsfe19.lga...
How can I create an ArrayList in the older version of .NET that does not
require the expensive Boxing and UnBoxing operations?

In my case it will be an ArrayList of structures of ordinal types.

Thanks.
You would need to create a collection class yourself and implement the
necessary methods/properties (including IEnumerable). The internal
implementation, to avoid boxing, would need to be an array of your
value-type values. (MyStructure[] mArray). You would also need to
implement your own handling of adding and removing from the array (note:
probably want to create an array large enough to handle the most common size
or most common maximum size) and only increase the size when you run out of
elements in the internal array.

HTH,
Mythran
Nov 3 '06 #2

P: n/a

Peter Olcott wrote:
How can I create an ArrayList in the older version of .NET that does not require
the expensive Boxing and UnBoxing operations?

In my case it will be an ArrayList of structures of ordinal types.
1. Have you determined that boxing and unboxing are in fact causing
significant performance degradation in your application? That is, are
you trying to optimize a priori, or do you already have a performance
problem you're trying to resolve?

2. Does it have to be an ArrayList? Or can you use an array? Do you
need to dynamically add / remove items?

If you do indeed have a performance problem caused by boxing and
unboxing, and you need a dynamic structure, then you'll have to build
your own.

Nov 3 '06 #3

P: n/a
What you are describing is called a Strongly Typed Collection.
http://www.google.com/search?q=stron...ed+collections

You should be able to find a number of free add-ins that will make
creating them alot easier.
http://www.google.com/search?q=stron...lection+add-in

If you are dealing with strings you can use the StringCollection and
StringDictionary in the System.Collections.Specialized namespace.
http://msdn2.microsoft.com/en-gb/lib...80,en-us).aspx
On Nov 3, 11:03 am, "Peter Olcott" <NoS...@SeeScreen.comwrote:
How can I create an ArrayList in the older version of .NET that does not require
the expensive Boxing and UnBoxing operations?

In my case it will be an ArrayList of structures of ordinal types.

Thanks.
Nov 3 '06 #4

P: n/a
Those are good links, Bill, but they don't address the OP's problem.

Remember that the original question was how to avoid boxing and
unboxing. Any collection that derives from CollectionBase will store
Object, and so require boxing and unboxing for value types.

The only way to avoid boxing overhead is to write your own collection
class that wraps an array of the value type in question. However,
before going down that road, it's important to determine that boxing is
indeed a problem.

Bill Rodenbaugh wrote:
What you are describing is called a Strongly Typed Collection.
http://www.google.com/search?q=stron...ed+collections

You should be able to find a number of free add-ins that will make
creating them alot easier.
http://www.google.com/search?q=stron...lection+add-in

If you are dealing with strings you can use the StringCollection and
StringDictionary in the System.Collections.Specialized namespace.
http://msdn2.microsoft.com/en-gb/lib...80,en-us).aspx
On Nov 3, 11:03 am, "Peter Olcott" <NoS...@SeeScreen.comwrote:
How can I create an ArrayList in the older version of .NET that does not require
the expensive Boxing and UnBoxing operations?

In my case it will be an ArrayList of structures of ordinal types.
Nov 3 '06 #5

P: n/a

"Bruce Wood" <br*******@canada.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.com...
Those are good links, Bill, but they don't address the OP's problem.

Remember that the original question was how to avoid boxing and
unboxing. Any collection that derives from CollectionBase will store
Object, and so require boxing and unboxing for value types.

The only way to avoid boxing overhead is to write your own collection
class that wraps an array of the value type in question. However,
before going down that road, it's important to determine that boxing is
indeed a problem.
My response time can not exceed 1/10 second. The class is currently implemented
in C++ using std::vector. I can not afford any degradation in the performance of
this class when ported to .NET.
>
Bill Rodenbaugh wrote:
>What you are describing is called a Strongly Typed Collection.
http://www.google.com/search?q=stron...ed+collections

You should be able to find a number of free add-ins that will make
creating them alot easier.
http://www.google.com/search?q=stron...lection+add-in

If you are dealing with strings you can use the StringCollection and
StringDictionary in the System.Collections.Specialized namespace.
http://msdn2.microsoft.com/en-gb/lib...80,en-us).aspx
On Nov 3, 11:03 am, "Peter Olcott" <NoS...@SeeScreen.comwrote:
How can I create an ArrayList in the older version of .NET that does not
require
the expensive Boxing and UnBoxing operations?

In my case it will be an ArrayList of structures of ordinal types.

Nov 3 '06 #6

P: n/a
Peter Olcott wrote:
"Bruce Wood" <br*******@canada.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.com...
>>
Remember that the original question was how to avoid boxing and
unboxing. Any collection that derives from CollectionBase will store
Object, and so require boxing and unboxing for value types.

The only way to avoid boxing overhead is to write your own collection
class that wraps an array of the value type in question. However,
before going down that road, it's important to determine that boxing is
indeed a problem.

My response time can not exceed 1/10 second. The class is currently implemented
in C++ using std::vector. I can not afford any degradation in the performance of
this class when ported to .NET.
You can box and unbox a lot of variables before it is noticeable in
1/10 second time intervals.

Arne
Nov 3 '06 #7

P: n/a

Peter Olcott wrote:
"Bruce Wood" <br*******@canada.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.com...
Those are good links, Bill, but they don't address the OP's problem.

Remember that the original question was how to avoid boxing and
unboxing. Any collection that derives from CollectionBase will store
Object, and so require boxing and unboxing for value types.

The only way to avoid boxing overhead is to write your own collection
class that wraps an array of the value type in question. However,
before going down that road, it's important to determine that boxing is
indeed a problem.

My response time can not exceed 1/10 second. The class is currently implemented
in C++ using std::vector. I can not afford any degradation in the performance of
this class when ported to .NET.
Is there a particular reason why you're porting to .NET 1.1? .NET 2.0
is far better.

Nov 3 '06 #8

P: n/a

"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk...
Peter Olcott wrote:
>"Bruce Wood" <br*******@canada.comwrote in message
news:11*********************@m73g2000cwd.googlegr oups.com...
>>>
Remember that the original question was how to avoid boxing and
unboxing. Any collection that derives from CollectionBase will store
Object, and so require boxing and unboxing for value types.

The only way to avoid boxing overhead is to write your own collection
class that wraps an array of the value type in question. However,
before going down that road, it's important to determine that boxing is
indeed a problem.

My response time can not exceed 1/10 second. The class is currently
implemented in C++ using std::vector. I can not afford any degradation in the
performance of this class when ported to .NET.

You can box and unbox a lot of variables before it is noticeable in
1/10 second time intervals.

Arne
By what factor does a simple integer comparison in a fixed array of integers to
single integer take longer when boxing an unboxing is adding? (Note the simple
comparision itself takes one machine clock). Even if unboxing takes only one
machine clock, we have now doubled the time required.
Nov 3 '06 #9

P: n/a
"Peter Olcott" <No****@SeeScreen.comwrote in message
news:mF******************@newsfe24.lga...
>
By what factor does a simple integer comparison in a fixed array of
integers to single integer take longer when boxing an unboxing is adding?
(Note the simple comparision itself takes one machine clock). Even if
unboxing takes only one machine clock, we have now doubled the time
required.
Doubling a tiny amount of time still results in a tiny amount of time. You'd
have to do a proper performance analysis before determining that
boxing/unboxing was significant.

///ark
Nov 3 '06 #10

P: n/a

"Mark Wilden" <mw*****@communitymtm.comwrote in message
news:ub****************@TK2MSFTNGP03.phx.gbl...
"Peter Olcott" <No****@SeeScreen.comwrote in message
news:mF******************@newsfe24.lga...
>>
By what factor does a simple integer comparison in a fixed array of integers
to single integer take longer when boxing an unboxing is adding? (Note the
simple comparision itself takes one machine clock). Even if unboxing takes
only one machine clock, we have now doubled the time required.

Doubling a tiny amount of time still results in a tiny amount of time. You'd
have to do a proper performance analysis before determining that
boxing/unboxing was significant.

///ark
How many clock cycles does one unboxing operation take?
Nov 4 '06 #11

P: n/a
Peter Olcott wrote:
"Mark Wilden" <mw*****@communitymtm.comwrote in message
news:ub****************@TK2MSFTNGP03.phx.gbl...
>Doubling a tiny amount of time still results in a tiny amount of time. You'd
have to do a proper performance analysis before determining that
boxing/unboxing was significant.
How many clock cycles does one unboxing operation take?
The little program attached below gives on my PC:

integer array: 0,046875
object array: 1,515625

With the uncertainty always present in that kind of micro
benchmarks, that says:

7 million box+unbox per second

Your stuff runs in 0.1 second. If we say that 1/100 overhead
is the acceptable, then you can box and unbox 7000 times in
your code.

Arne
using System;
using System.Collections.Generic;

namespace E
{
public class MainClass
{
private const int N = 10000000;
public static void Main(string[] args)
{
int[] ia = new int[N];
DateTime dt1 = DateTime.Now;
for(int i = 0; i < N; i++)
{
ia[i] = i;
}
for(int i = 0; i < N; i++)
{
if(ia[i] != i)
{
Console.WriteLine("Oops");
Environment.Exit(1);
}
}
DateTime dt2 = DateTime.Now;
object[] oa = new object[N];
Console.WriteLine("integer array: " + (dt2 - dt1).TotalSeconds);
DateTime dt3 = DateTime.Now;
for(int i = 0; i < N; i++)
{
oa[i] = i;
}
for(int i = 0; i < N; i++)
{
if((int)oa[i] != i)
{
Console.WriteLine("Oops");
Environment.Exit(1);
}
}
DateTime dt4 = DateTime.Now;
Console.WriteLine("object array: " + (dt4 - dt3).TotalSeconds);
Console.ReadKey();
}
}
}
Nov 4 '06 #12

P: n/a
That would make it infeasible. Generics completely bypass boxing and unboxing,
right?

"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk...
Peter Olcott wrote:
>"Mark Wilden" <mw*****@communitymtm.comwrote in message
news:ub****************@TK2MSFTNGP03.phx.gbl...
>>Doubling a tiny amount of time still results in a tiny amount of time. You'd
have to do a proper performance analysis before determining that
boxing/unboxing was significant.
>How many clock cycles does one unboxing operation take?

The little program attached below gives on my PC:

integer array: 0,046875
object array: 1,515625

With the uncertainty always present in that kind of micro
benchmarks, that says:

7 million box+unbox per second

Your stuff runs in 0.1 second. If we say that 1/100 overhead
is the acceptable, then you can box and unbox 7000 times in
your code.

Arne
using System;
using System.Collections.Generic;

namespace E
{
public class MainClass
{
private const int N = 10000000;
public static void Main(string[] args)
{
int[] ia = new int[N];
DateTime dt1 = DateTime.Now;
for(int i = 0; i < N; i++)
{
ia[i] = i;
}
for(int i = 0; i < N; i++)
{
if(ia[i] != i)
{
Console.WriteLine("Oops");
Environment.Exit(1);
}
}
DateTime dt2 = DateTime.Now;
object[] oa = new object[N];
Console.WriteLine("integer array: " + (dt2 - dt1).TotalSeconds);
DateTime dt3 = DateTime.Now;
for(int i = 0; i < N; i++)
{
oa[i] = i;
}
for(int i = 0; i < N; i++)
{
if((int)oa[i] != i)
{
Console.WriteLine("Oops");
Environment.Exit(1);
}
}
DateTime dt4 = DateTime.Now;
Console.WriteLine("object array: " + (dt4 - dt3).TotalSeconds);
Console.ReadKey();
}
}
}

Nov 5 '06 #13

P: n/a

Peter Olcott wrote:
That would make it infeasible. Generics completely bypass boxing and unboxing,
right?
Yes. Generics allow the compiler to create aggregate structures that
contain value types directly, rather than structures that contain
Object and so require boxing.

That's why I asked why you weren't using .NET 2.0: generics solve your
problem nicely, but they're only available starting in .NET 2.0.

Nov 5 '06 #14

P: n/a
Peter Olcott <No****@SeeScreen.comwrote:
That would make it infeasible. Generics completely bypass boxing and unboxing,
right?
Assuming you mean using List<intinstead of ArrayList, etc, then yes.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 5 '06 #15

P: n/a

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Peter Olcott <No****@SeeScreen.comwrote:
>That would make it infeasible. Generics completely bypass boxing and
unboxing,
right?

Assuming you mean using List<intinstead of ArrayList, etc, then yes.
I need the C# equivalent of std::vector. It must be able to dynamically grow in
size, and it must not have any more overhead than an unmanaged array of struct.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Nov 5 '06 #16

P: n/a

"Bruce Wood" <br*******@canada.comwrote in message
news:11**********************@f16g2000cwb.googlegr oups.com...
>
Peter Olcott wrote:
>That would make it infeasible. Generics completely bypass boxing and
unboxing,
right?

Yes. Generics allow the compiler to create aggregate structures that
contain value types directly, rather than structures that contain
Object and so require boxing.
I need the C# equivalent of std::vector. It must be able to dynamically grow in
size, and it must not have any more overhead than an unmanaged array of struct.
Can generics handle this?
>
That's why I asked why you weren't using .NET 2.0: generics solve your
problem nicely, but they're only available starting in .NET 2.0.

Nov 5 '06 #17

P: n/a
Peter Olcott <No****@SeeScreen.comwrote:
Assuming you mean using List<intinstead of ArrayList, etc, then yes.

I need the C# equivalent of std::vector. It must be able to dynamically grow in
size, and it must not have any more overhead than an unmanaged array of struct.
Well, there will be a *slight* overhead when it comes to accessing
(because it'll need to check the size against the size of the list as
well as then against the size of the backing array) but yes, List<Tis
basically what you want.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 5 '06 #18

P: n/a
Peter Olcott wrote:
"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
>integer array: 0,046875
object array: 1,515625

With the uncertainty always present in that kind of micro
benchmarks, that says:

7 million box+unbox per second

Your stuff runs in 0.1 second. If we say that 1/100 overhead
is the acceptable, then you can box and unbox 7000 times in
your code.
That would make it infeasible. Generics completely bypass boxing and unboxing,
right?
You need to do more than 7000 boxing and unboxing every 1/10 seconds
with less overhead than 1/100 ?

I would call that rather unusual requirements.

Yes - generics will avoid boxing and unboxing, but it will
add some overhead too.

Arne
Nov 5 '06 #19

P: n/a
Peter Olcott wrote:
I need the C# equivalent of std::vector. It must be able to dynamically grow in
size, and it must not have any more overhead than an unmanaged array of struct.
Can generics handle this?
I would say that the two requirements:
1) be able to dynamically grow
2) must not have any more overhead than an unmanaged array
are in conflict.

Nothing is free.

I extended my previous posted example and get:

save retrieve
integer array : 0,08 0,03
object array : 3,05 0,08
array list : 4,67 0,16
generic list : 0,31 0,05

Arne
Nov 5 '06 #20

P: n/a

"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk...
Peter Olcott wrote:
>"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
>>integer array: 0,046875
object array: 1,515625

With the uncertainty always present in that kind of micro
benchmarks, that says:

7 million box+unbox per second

Your stuff runs in 0.1 second. If we say that 1/100 overhead
is the acceptable, then you can box and unbox 7000 times in
your code.
>That would make it infeasible. Generics completely bypass boxing and
unboxing, right?

You need to do more than 7000 boxing and unboxing every 1/10 seconds
with less overhead than 1/100 ?

I would call that rather unusual requirements.

Yes - generics will avoid boxing and unboxing, but it will
add some overhead too.

Arne
Take a look a the technology:

--
Patented SeeScreen enables
programs to see anything on
the computer display screen
www.SeeScreen.com
Nov 5 '06 #21

P: n/a

"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk...
Peter Olcott wrote:
>I need the C# equivalent of std::vector. It must be able to dynamically grow
in
size, and it must not have any more overhead than an unmanaged array of
struct.
Can generics handle this?

I would say that the two requirements:
1) be able to dynamically grow
2) must not have any more overhead than an unmanaged array
are in conflict.

Nothing is free.
Unmanaged array access costs no more than unmanaged array access, I think it is
about one clock.
I extended my previous posted example and get:

save retrieve
integer array : 0,08 0,03
object array : 3,05 0,08
array list : 4,67 0,16
generic list : 0,31 0,05

Arne

Nov 5 '06 #22

P: n/a
Peter Olcott wrote:
"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk...
>Peter Olcott wrote:
>>I need the C# equivalent of std::vector. It must be able to dynamically grow
in
size, and it must not have any more overhead than an unmanaged array of
struct.
Can generics handle this?
I would say that the two requirements:
1) be able to dynamically grow
2) must not have any more overhead than an unmanaged array
are in conflict.

Nothing is free.

Unmanaged array access costs no more than unmanaged array access, I think it is
about one clock.
The functionality offered by a list will cost. Maybe only in adding
and not in getting. But it will cost.

That should be rather obvious.

Arne
Nov 5 '06 #23

P: n/a

"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk...
Peter Olcott wrote:
>"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk. ..
>>Peter Olcott wrote:
I need the C# equivalent of std::vector. It must be able to dynamically
grow in
size, and it must not have any more overhead than an unmanaged array of
struct.
Can generics handle this?
I would say that the two requirements:
1) be able to dynamically grow
2) must not have any more overhead than an unmanaged array
are in conflict.

Nothing is free.

Unmanaged array access costs no more than unmanaged array access, I think it
is about one clock.

The functionality offered by a list will cost. Maybe only in adding
and not in getting. But it will cost.
std::vector provides access time equal to the access time of unmanaged array
access, yet can dynamically grow.
Does .NET have anything with EXACTLY these performance characteristics?
>
That should be rather obvious.

Arne

Nov 6 '06 #24

P: n/a
Peter Olcott <No****@SeeScreen.comwrote:
The functionality offered by a list will cost. Maybe only in adding
and not in getting. But it will cost.

std::vector provides access time equal to the access time of unmanaged array
access, yet can dynamically grow.
Does .NET have anything with EXACTLY these performance characteristics?
Frankly, I doubt that std::vector provides that, to be honest. Assuming
it's an array + size, you need to do a size check before the array
access, so there's a performance penalty there, even if it's really
small.

Certainly I haven't seen anything in .NET which has *no* performance
penalty over using arrays. You could probably write a list which would
return potentially bad data rather than throwing the appropriate
exception if, say, you had a backing array of size 5, a list of size 2,
and asked for element 4. I'd rather have correctness with the tiny
performance penalty though...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 6 '06 #25

P: n/a
If you only store the valueType in ArraryList,may be useedthe template
would be help.
Out of this way ,i couldn't think out what way to fix

May be help for you
On Nov 4, 3:03 am, "Peter Olcott" <NoS...@SeeScreen.comwrote:
How can I create an ArrayList in the older version of .NET that does not require
the expensive Boxing and UnBoxing operations?

In my case it will be an ArrayList of structures of ordinal types.

Thanks.
Nov 6 '06 #26

P: n/a

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Peter Olcott <No****@SeeScreen.comwrote:
The functionality offered by a list will cost. Maybe only in adding
and not in getting. But it will cost.

std::vector provides access time equal to the access time of unmanaged array
access, yet can dynamically grow.
Does .NET have anything with EXACTLY these performance characteristics?

Frankly, I doubt that std::vector provides that, to be honest. Assuming
it's an array + size, you need to do a size check before the array
access, so there's a performance penalty there, even if it's really
small.
No there is no size check, and this cost is not be really small, it at least
doubles the access time.
>
Certainly I haven't seen anything in .NET which has *no* performance
penalty over using arrays. You could probably write a list which would
return potentially bad data rather than throwing the appropriate
exception if, say, you had a backing array of size 5, a list of size 2,
and asked for element 4. I'd rather have correctness with the tiny
performance penalty though...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Nov 6 '06 #27

P: n/a

"Peter Olcott" <No****@SeeScreen.comwrote in message
news:34******************@newsfe20.lga...
|
| "Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
| news:MP************************@msnews.microsoft.c om...
| Peter Olcott <No****@SeeScreen.comwrote:
| The functionality offered by a list will cost. Maybe only in adding
| and not in getting. But it will cost.
| >>
| >std::vector provides access time equal to the access time of unmanaged
array
| >access, yet can dynamically grow.
| >Does .NET have anything with EXACTLY these performance characteristics?
| >
| Frankly, I doubt that std::vector provides that, to be honest. Assuming
| it's an array + size, you need to do a size check before the array
| access, so there's a performance penalty there, even if it's really
| small.
|
| No there is no size check, and this cost is not be really small, it at
least
| doubles the access time.
|
This is definitely not true, consider following small sample:

#include <vector>
int main(int argc, char *argv[])
{
size_t size = 100;
std::vector<intarray(size); // make room for 10 integers,
// and initialize them to 0
// do something with them:
for(int i=0; i<size; ++i){
array[i] = i;
}
// break here, disassembly follows
int v = array[55];
return 0;
}

comments added [n]

004025e8 85ff test edi,edi [1]
004025ea 740a je vect!main+0x56 (004025f6)
004025ec 2bdf sub ebx,edi [2]
004025ee c1fb02 sar ebx,2 [3]
004025f1 83fb37 cmp ebx,37h [4]
004025f4 7705 ja vect!main+0x5b (004025fb)
004025f6 e8f1070000 call vect!_invalid_parameter_noinfo (00402dec)
004025fb 8b8fdc000000 mov ecx,dword ptr [edi+0DCh]
ds:0023:00324c3c=00000037 [5]

[1] checks array base pointer for null (non initialized)
[2] calculate length of array in bytes (edi = base, edx points to past end
of array)
[3] convert to length in int's (divide by 4)
[4] index < length of array
[5] move int at edi+55 -ecx

You see, there is a pointer validation check and a bounds check for each
access. This accounts for 6 instructions, supposed index is within bounds.
Exactly the same is done in .NET when accessing array elements.
Willy.

Nov 6 '06 #28

P: n/a

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:u7**************@TK2MSFTNGP02.phx.gbl...
>
"Peter Olcott" <No****@SeeScreen.comwrote in message
news:34******************@newsfe20.lga...
|
| "Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
| news:MP************************@msnews.microsoft.c om...
| Peter Olcott <No****@SeeScreen.comwrote:
| The functionality offered by a list will cost. Maybe only in adding
| and not in getting. But it will cost.
| >>
| >std::vector provides access time equal to the access time of unmanaged
array
| >access, yet can dynamically grow.
| >Does .NET have anything with EXACTLY these performance characteristics?
| >
| Frankly, I doubt that std::vector provides that, to be honest. Assuming
| it's an array + size, you need to do a size check before the array
| access, so there's a performance penalty there, even if it's really
| small.
|
| No there is no size check, and this cost is not be really small, it at
least
| doubles the access time.
|
This is definitely not true, consider following small sample:

#include <vector>
int main(int argc, char *argv[])
{
size_t size = 100;
std::vector<intarray(size); // make room for 10 integers,
// and initialize them to 0
// do something with them:
for(int i=0; i<size; ++i){
array[i] = i;
}
// break here, disassembly follows
int v = array[55];
return 0;
}

comments added [n]

004025e8 85ff test edi,edi [1]
004025ea 740a je vect!main+0x56 (004025f6)
004025ec 2bdf sub ebx,edi [2]
004025ee c1fb02 sar ebx,2 [3]
004025f1 83fb37 cmp ebx,37h [4]
004025f4 7705 ja vect!main+0x5b (004025fb)
004025f6 e8f1070000 call vect!_invalid_parameter_noinfo (00402dec)
004025fb 8b8fdc000000 mov ecx,dword ptr [edi+0DCh]
ds:0023:00324c3c=00000037 [5]

[1] checks array base pointer for null (non initialized)
[2] calculate length of array in bytes (edi = base, edx points to past end
of array)
[3] convert to length in int's (divide by 4)
[4] index < length of array
[5] move int at edi+55 -ecx

You see, there is a pointer validation check and a bounds check for each
access. This accounts for 6 instructions, supposed index is within bounds.
You are not supposed to get range checking unless you explicitly ask for it by
invoking the std::vector:at(n) member function.
Exactly the same is done in .NET when accessing array elements.
Willy.

Nov 6 '06 #29

P: n/a

"Peter Olcott" <No****@SeeScreen.comwrote in message
news:mb******************@newsfe24.lga...
|
| "Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
| news:u7**************@TK2MSFTNGP02.phx.gbl...
| >
| "Peter Olcott" <No****@SeeScreen.comwrote in message
| news:34******************@newsfe20.lga...
| |
| | "Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
| | news:MP************************@msnews.microsoft.c om...
| | Peter Olcott <No****@SeeScreen.comwrote:
| | The functionality offered by a list will cost. Maybe only in
adding
| | and not in getting. But it will cost.
| | >>
| | >std::vector provides access time equal to the access time of
unmanaged
| array
| | >access, yet can dynamically grow.
| | >Does .NET have anything with EXACTLY these performance
characteristics?
| | >
| | Frankly, I doubt that std::vector provides that, to be honest.
Assuming
| | it's an array + size, you need to do a size check before the array
| | access, so there's a performance penalty there, even if it's really
| | small.
| |
| | No there is no size check, and this cost is not be really small, it at
| least
| | doubles the access time.
| |
| >
| >
| This is definitely not true, consider following small sample:
| >
| #include <vector>
| int main(int argc, char *argv[])
| {
| size_t size = 100;
| std::vector<intarray(size); // make room for 10 integers,
| // and initialize them to 0
| // do something with them:
| for(int i=0; i<size; ++i){
| array[i] = i;
| }
| // break here, disassembly follows
| int v = array[55];
| return 0;
| }
| >
| comments added [n]
| >
| 004025e8 85ff test edi,edi [1]
| 004025ea 740a je vect!main+0x56 (004025f6)
| 004025ec 2bdf sub ebx,edi [2]
| 004025ee c1fb02 sar ebx,2 [3]
| 004025f1 83fb37 cmp ebx,37h [4]
| 004025f4 7705 ja vect!main+0x5b (004025fb)
| 004025f6 e8f1070000 call vect!_invalid_parameter_noinfo
(00402dec)
| 004025fb 8b8fdc000000 mov ecx,dword ptr [edi+0DCh]
| ds:0023:00324c3c=00000037 [5]
| >
| [1] checks array base pointer for null (non initialized)
| [2] calculate length of array in bytes (edi = base, edx points to past
end
| of array)
| [3] convert to length in int's (divide by 4)
| [4] index < length of array
| [5] move int at edi+55 -ecx
| >
| You see, there is a pointer validation check and a bounds check for each
| access. This accounts for 6 instructions, supposed index is within
bounds.
|
| You are not supposed to get range checking unless you explicitly ask for
it by
| invoking the std::vector:at(n) member function.
|

This is an implementation detail. The std library as supplied by MSFT
(Dinkumware's implementation)) since 7.1 does range checking, don't know
about other iplementations though. Point is that you should not rely on
this, the standard does not enforce operator[] to be 'unchecked' AFAIK.
The major difference between operator[] and at() access is that the former
calls a "crt debugger" hook followed by a 'drwatson' call, while the latter
throws an "out_of_range" exception.

Willy.


Nov 6 '06 #30

P: n/a

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:O0****************@TK2MSFTNGP02.phx.gbl...
|
| "Peter Olcott" <No****@SeeScreen.comwrote in message
| news:mb******************@newsfe24.lga...
||
|| "Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
|| news:u7**************@TK2MSFTNGP02.phx.gbl...
|| >
|| "Peter Olcott" <No****@SeeScreen.comwrote in message
|| news:34******************@newsfe20.lga...
|| |
|| | "Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
|| | news:MP************************@msnews.microsoft.c om...
|| | Peter Olcott <No****@SeeScreen.comwrote:
|| | The functionality offered by a list will cost. Maybe only in
| adding
|| | and not in getting. But it will cost.
|| | >>
|| | >std::vector provides access time equal to the access time of
| unmanaged
|| array
|| | >access, yet can dynamically grow.
|| | >Does .NET have anything with EXACTLY these performance
| characteristics?
|| | >
|| | Frankly, I doubt that std::vector provides that, to be honest.
| Assuming
|| | it's an array + size, you need to do a size check before the array
|| | access, so there's a performance penalty there, even if it's really
|| | small.
|| |
|| | No there is no size check, and this cost is not be really small, it
at
|| least
|| | doubles the access time.
|| |
|| >
|| >
|| This is definitely not true, consider following small sample:
|| >
|| #include <vector>
|| int main(int argc, char *argv[])
|| {
|| size_t size = 100;
|| std::vector<intarray(size); // make room for 10 integers,
|| // and initialize them to 0
|| // do something with them:
|| for(int i=0; i<size; ++i){
|| array[i] = i;
|| }
|| // break here, disassembly follows
|| int v = array[55];
|| return 0;
|| }
|| >
|| comments added [n]
|| >
|| 004025e8 85ff test edi,edi [1]
|| 004025ea 740a je vect!main+0x56 (004025f6)
|| 004025ec 2bdf sub ebx,edi [2]
|| 004025ee c1fb02 sar ebx,2 [3]
|| 004025f1 83fb37 cmp ebx,37h [4]
|| 004025f4 7705 ja vect!main+0x5b (004025fb)
|| 004025f6 e8f1070000 call vect!_invalid_parameter_noinfo
| (00402dec)
|| 004025fb 8b8fdc000000 mov ecx,dword ptr [edi+0DCh]
|| ds:0023:00324c3c=00000037 [5]
|| >
|| [1] checks array base pointer for null (non initialized)
|| [2] calculate length of array in bytes (edi = base, edx points to past
| end
|| of array)
|| [3] convert to length in int's (divide by 4)
|| [4] index < length of array
|| [5] move int at edi+55 -ecx
|| >
|| You see, there is a pointer validation check and a bounds check for
each
|| access. This accounts for 6 instructions, supposed index is within
| bounds.
||
|| You are not supposed to get range checking unless you explicitly ask for
| it by
|| invoking the std::vector:at(n) member function.
||
|
| This is an implementation detail. The std library as supplied by MSFT
| (Dinkumware's implementation)) since 7.1 does range checking, don't know
| about other iplementations though. Point is that you should not rely on
| this, the standard does not enforce operator[] to be 'unchecked' AFAIK.
| The major difference between operator[] and at() access is that the former
| calls a "crt debugger" hook followed by a 'drwatson' call, while the
latter
| throws an "out_of_range" exception.
|
| Willy.
|

Forgot to mention that this behavior can be turned of by means of
the -D_SECURE_SCL switch or in code using:
#define _SECURE_SCL 0
Note that by doing so, you throw away all security related enhancements.

Willy.

Nov 6 '06 #31

P: n/a
Peter Olcott wrote:
"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
>The functionality offered by a list will cost. Maybe only in adding
and not in getting. But it will cost.

std::vector provides access time equal to the access time of unmanaged array
access, yet can dynamically grow.
Does .NET have anything with EXACTLY these performance characteristics?
Hm.

GCC 3.2 with -O3:

integer array 0.06 0.03
vector 0.33 0.06

BCB 5.6:

integer array 0.06 0.03
vector 0.33 0.05

VC++ 7.1 with /Ox:

integer array 0.06 0.03
vector 0.44 0.05

Results fluctuate a bit, but at average integer array
is faster than vector.

Arne

PS: Ask for code if interested.
Nov 7 '06 #32

P: n/a

"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk...
Peter Olcott wrote:
>"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
>>The functionality offered by a list will cost. Maybe only in adding
and not in getting. But it will cost.

std::vector provides access time equal to the access time of unmanaged array
access, yet can dynamically grow.
Does .NET have anything with EXACTLY these performance characteristics?

Hm.

GCC 3.2 with -O3:

integer array 0.06 0.03
vector 0.33 0.06

BCB 5.6:

integer array 0.06 0.03
vector 0.33 0.05

VC++ 7.1 with /Ox:

integer array 0.06 0.03
vector 0.44 0.05

Results fluctuate a bit, but at average integer array
is faster than vector.

Arne

PS: Ask for code if interested.
What are the two columns?
Nov 7 '06 #33

P: n/a
Peter Olcott wrote:
"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk...
>Peter Olcott wrote:
>>"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
The functionality offered by a list will cost. Maybe only in adding
and not in getting. But it will cost.
std::vector provides access time equal to the access time of unmanaged array
access, yet can dynamically grow.
Does .NET have anything with EXACTLY these performance characteristics?
Hm.

GCC 3.2 with -O3:

integer array 0.06 0.03
vector 0.33 0.06

BCB 5.6:

integer array 0.06 0.03
vector 0.33 0.05

VC++ 7.1 with /Ox:

integer array 0.06 0.03
vector 0.44 0.05

Results fluctuate a bit, but at average integer array
is faster than vector.

Arne

PS: Ask for code if interested.

What are the two columns?
Storing and retrieving.

Arne
Nov 8 '06 #34

P: n/a

"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk...
Peter Olcott wrote:
>"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk. ..
>>Peter Olcott wrote:
"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
The functionality offered by a list will cost. Maybe only in adding
and not in getting. But it will cost.
std::vector provides access time equal to the access time of unmanaged
array access, yet can dynamically grow.
Does .NET have anything with EXACTLY these performance characteristics?
Hm.

GCC 3.2 with -O3:

integer array 0.06 0.03
vector 0.33 0.06

BCB 5.6:

integer array 0.06 0.03
vector 0.33 0.05

VC++ 7.1 with /Ox:

integer array 0.06 0.03
vector 0.44 0.05

Results fluctuate a bit, but at average integer array
is faster than vector.

Arne

PS: Ask for code if interested.

What are the two columns?

Storing and retrieving.

Arne
Is that storing using push_back(), or storing using operator[] ?
I would think that the former would be much slower than the latter.
Nov 8 '06 #35

P: n/a
Peter Olcott wrote:
"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk...
>Peter Olcott wrote:
>>"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk.. .
Peter Olcott wrote:
"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
>The functionality offered by a list will cost. Maybe only in adding
>and not in getting. But it will cost.
std::vector provides access time equal to the access time of unmanaged
array access, yet can dynamically grow.
Does .NET have anything with EXACTLY these performance characteristics?
Hm.

GCC 3.2 with -O3:

integer array 0.06 0.03
vector 0.33 0.06

BCB 5.6:

integer array 0.06 0.03
vector 0.33 0.05

VC++ 7.1 with /Ox:

integer array 0.06 0.03
vector 0.44 0.05

Results fluctuate a bit, but at average integer array
is faster than vector.
>>What are the two columns?
>Storing and retrieving.
Is that storing using push_back(), or storing using operator[] ?
I would think that the former would be much slower than the latter.
push_back

[] will crash unless the array is preallocated - in which case
a simple array could just as well be used.

Arne
Nov 10 '06 #36

P: n/a

"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk...
Peter Olcott wrote:
>"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk. ..
>>Peter Olcott wrote:
"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk. ..
Peter Olcott wrote:
>"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
>>The functionality offered by a list will cost. Maybe only in adding
>>and not in getting. But it will cost.
>std::vector provides access time equal to the access time of unmanaged
>array access, yet can dynamically grow.
>Does .NET have anything with EXACTLY these performance characteristics?
Hm.
>
GCC 3.2 with -O3:
>
integer array 0.06 0.03
vector 0.33 0.06
>
BCB 5.6:
>
integer array 0.06 0.03
vector 0.33 0.05
>
VC++ 7.1 with /Ox:
>
integer array 0.06 0.03
vector 0.44 0.05
>
Results fluctuate a bit, but at average integer array
is faster than vector.
>>>What are the two columns?
>>Storing and retrieving.
>Is that storing using push_back(), or storing using operator[] ?
I would think that the former would be much slower than the latter.

push_back

[] will crash unless the array is preallocated - in which case
a simple array could just as well be used.

Arne
When I am talking about array access, I am talking about reading from the array.
If .NET takes more than 50% more time to read from an array of scalar types, it
would be unacceptable for my application. With Boxing and UnBoxing we have much
more than a 50% cost penalty. I am not sure about the cost penalty (if any) for
generics.
Nov 15 '06 #37

P: n/a
"Peter Olcott" <No****@SeeScreen.comwrote in message
news:QO*****************@newsfe17.lga...
>
When I am talking about array access, I am talking about reading from
the array. If .NET takes more than 50% more time to read from an array
of scalar types, it would be unacceptable for my application. With
Boxing and UnBoxing we have much more than a 50% cost penalty. I am
not sure about the cost penalty (if any) for generics.
As has been suggested in the past, You should set up a realistic proof
of concept to see if this is the issue that you think it is. If, after
testing, you determine that the performance hit is unacceptable, THEN
you should start working on ways around the issue.

Bill
Nov 15 '06 #38

P: n/a

"Bill Butler" <qw****@asdf.comwrote in message
news:CaH6h.6165$dh7.4013@trnddc01...
"Peter Olcott" <No****@SeeScreen.comwrote in message
news:QO*****************@newsfe17.lga...
>>
When I am talking about array access, I am talking about reading from the
array. If .NET takes more than 50% more time to read from an array of scalar
types, it would be unacceptable for my application. With Boxing and UnBoxing
we have much more than a 50% cost penalty. I am not sure about the cost
penalty (if any) for generics.

As has been suggested in the past, You should set up a realistic proof of
concept to see if this is the issue that you think it is. If, after testing,
you determine that the performance hit is unacceptable, THEN you should start
working on ways around the issue.

Bill
Its not worth spending the learning curve that is required. If I could know in
advance that benchmarks prove that the read access time to scalar types is
comparable to that to read access time of unmanaged array access, then it might
be worth the learning curve to pursue further.
Nov 15 '06 #39

P: n/a
"Peter Olcott" <No****@SeeScreen.comwrote in message
news:4Z***********@newsfe22.lga...
<snip>
Its not worth spending the learning curve that is required. If I could
know in advance that benchmarks prove that the read access time to
scalar types is comparable to that to read access time of unmanaged
array access, then it might be worth the learning curve to pursue
further.
Is your current App running so close to the edge that you cannot afford
any spare clock cycles?

Doing a quick proof of concept shouldn't be THAT time consuming. Perhaps
you really can't afford the overhead, but you will never know if you
don't do a test

Bill

Nov 15 '06 #40

P: n/a

"Bill Butler" <qw****@asdf.comwrote in message
news:XLN6h.4599$Jd3.3273@trnddc07...
"Peter Olcott" <No****@SeeScreen.comwrote in message
news:4Z***********@newsfe22.lga...
<snip>
>Its not worth spending the learning curve that is required. If I could know
in advance that benchmarks prove that the read access time to scalar types is
comparable to that to read access time of unmanaged array access, then it
might be worth the learning curve to pursue further.

Is your current App running so close to the edge that you cannot afford any
spare clock cycles?
Its real-time, every clock cycle counts.
>
Doing a quick proof of concept shouldn't be THAT time consuming. Perhaps you
really can't afford the overhead, but you will never know if you don't do a
test
It requires buying a $500.00 compiler and learning .NET and C#. This is far too
much commitment when this can simply be a question answered by someone that
already knows the answer. In theory there is no reason why .NET generics, need
to be any slower at all than std::vector on read access. In theory there is no
reason why C# must be any slower than C++. Sometimes theory and practice do not
correspond.
>
Bill

Nov 16 '06 #41

P: n/a
On Wed, 15 Nov 2006 19:27:38 -0600, "Peter Olcott"
<No****@SeeScreen.comwrote:
In theory there is no reason why .NET generics, need
to be any slower at all than std::vector on read access. In theory there is no
reason why C# must be any slower than C++. Sometimes theory and practice do not
correspond.
I am only learning the beginnings of C#, but even I recognize that it
is bound to be slower than C or C++. I am willing to allow that as
long as I get something back in return. I am still hopeful about that,
but the jury is still out...

--
Posted via a free Usenet account from http://www.teranews.com

Nov 16 '06 #42

P: n/a
Peter Olcott wrote:
It requires buying a $500.00 compiler and learning .NET and C#. This is far too
much commitment when this can simply be a question answered by someone that
already knows the answer. In theory there is no reason why .NET generics, need
to be any slower at all than std::vector on read access. In theory there is no
reason why C# must be any slower than C++. Sometimes theory and practice do not
correspond.
The C# compiler is free.

Actually my tests showed the same overhead for read from C# List<int>
and C++ vector<int>. About 50% for both !

Arne
Nov 16 '06 #43

P: n/a

"Ben Newsam" <be********@ukonline.co.ukwrote in message
news:c9********************************@4ax.com...
On Wed, 15 Nov 2006 19:27:38 -0600, "Peter Olcott"
<No****@SeeScreen.comwrote:
>In theory there is no reason why .NET generics, need
to be any slower at all than std::vector on read access. In theory there is
no
reason why C# must be any slower than C++. Sometimes theory and practice do
not
correspond.

I am only learning the beginnings of C#, but even I recognize that it
is bound to be slower than C or C++. I am willing to allow that as
long as I get something back in return. I am still hopeful about that,
but the jury is still out...
..NET and C# do have an excellent design, and probably will be able to provide
the same performance as unmanaged native code eventually, if they do not already
do so. I need to know how well they do this now. The official word from
Microsoft is that managed C++ is faster than managed C#.
--
Posted via a free Usenet account from http://www.teranews.com

Nov 16 '06 #44

P: n/a

"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk...
Peter Olcott wrote:
>It requires buying a $500.00 compiler and learning .NET and C#. This is far
too much commitment when this can simply be a question answered by someone
that already knows the answer. In theory there is no reason why .NET
generics, need to be any slower at all than std::vector on read access. In
theory there is no reason why C# must be any slower than C++. Sometimes
theory and practice do not correspond.

The C# compiler is free.

Actually my tests showed the same overhead for read from C# List<int>
and C++ vector<int>. About 50% for both !

Arne
integer array: 0,046875
object array: 1,515625
32-fold more time?

How does this compare when we are testing read access between an integer array,
and the fastest way that .NET can provide integer array access, generics?
Nov 16 '06 #45

P: n/a
Peter Olcott wrote:
"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk...
>Peter Olcott wrote:
>>It requires buying a $500.00 compiler and learning .NET and C#. This is far
too much commitment when this can simply be a question answered by someone
that already knows the answer. In theory there is no reason why .NET
generics, need to be any slower at all than std::vector on read access. In
theory there is no reason why C# must be any slower than C++. Sometimes
theory and practice do not correspond.
The C# compiler is free.

Actually my tests showed the same overhead for read from C# List<int>
and C++ vector<int>. About 50% for both !

Arne

integer array: 0,046875
object array: 1,515625
32-fold more time?

How does this compare when we are testing read access between an integer array,
and the fastest way that .NET can provide integer array access, generics?
You are looking at the combined store and retrive numbers.

The split up were:

save retrieve
integer array : 0,08 0,03
object array : 3,05 0,08
array list : 4,67 0,16
generic list : 0,31 0,05

Arne
Nov 16 '06 #46

P: n/a
Ben Newsam wrote:
On Wed, 15 Nov 2006 19:27:38 -0600, "Peter Olcott"
<No****@SeeScreen.comwrote:
I am only learning the beginnings of C#, but even I recognize that it
is bound to be slower than C or C++. I am willing to allow that as
long as I get something back in return. I am still hopeful about that,
but the jury is still out...
Well - that is not obvious to me.

Why should optimization at compile time be better
than optimization first time run ?

Arne
Nov 16 '06 #47

P: n/a

"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk...
Peter Olcott wrote:
>"Arne Vajh°j" <ar**@vajhoej.dkwrote in message
news:45***********************@news.sunsite.dk. ..
>>Peter Olcott wrote:
It requires buying a $500.00 compiler and learning .NET and C#. This is far
too much commitment when this can simply be a question answered by someone
that already knows the answer. In theory there is no reason why .NET
generics, need to be any slower at all than std::vector on read access. In
theory there is no reason why C# must be any slower than C++. Sometimes
theory and practice do not correspond.
The C# compiler is free.

Actually my tests showed the same overhead for read from C# List<int>
and C++ vector<int>. About 50% for both !

Arne

integer array: 0,046875
object array: 1,515625
32-fold more time?

How does this compare when we are testing read access between an integer
array, and the fastest way that .NET can provide integer array access,
generics?

You are looking at the combined store and retrive numbers.

The split up were:

save retrieve
integer array : 0,08 0,03
object array : 3,05 0,08
array list : 4,67 0,16
generic list : 0,31 0,05

Arne
I did not understand these numbers:
(1) Is the comma intended to take tha place of a decimal point, or are there
four different numbers per line ?
(2) What are these numbers clocks per operation? Seconds per fixed number of
operations ?
(3) How do they compare to std::vector ?
Nov 16 '06 #48

P: n/a
On Wed, 15 Nov 2006 21:45:39 -0500, Arne Vajh°j <ar**@vajhoej.dk>
wrote:
>Ben Newsam wrote:
>On Wed, 15 Nov 2006 19:27:38 -0600, "Peter Olcott"
<No****@SeeScreen.comwrote:
I am only learning the beginnings of C#, but even I recognize that it
is bound to be slower than C or C++. I am willing to allow that as
long as I get something back in return. I am still hopeful about that,
but the jury is still out...

Well - that is not obvious to me.

Why should optimization at compile time be better
than optimization first time run ?
Faster. I wouldn't know about better.

--
Posted via a free Usenet account from http://www.teranews.com

Nov 16 '06 #49

P: n/a

"Ben Newsam" <be********@ukonline.co.ukwrote in message
news:p3********************************@4ax.com...
On Wed, 15 Nov 2006 21:45:39 -0500, Arne Vajh°j <ar**@vajhoej.dk>
wrote:
>>Ben Newsam wrote:
>>On Wed, 15 Nov 2006 19:27:38 -0600, "Peter Olcott"
<No****@SeeScreen.comwrote:
I am only learning the beginnings of C#, but even I recognize that it
is bound to be slower than C or C++. I am willing to allow that as
long as I get something back in return. I am still hopeful about that,
but the jury is still out...

Well - that is not obvious to me.

Why should optimization at compile time be better
than optimization first time run ?

Faster. I wouldn't know about better.

--
Posted via a free Usenet account from http://www.teranews.com
There are two factors: when you have the original source code more information
is provided so that a greater degree of changes can be made, and still derive
the same result. From a marketability point of view slow compile times effect
fewer users than slower run times, so you have more time to do a better job at
compile time. Neither of these two things is a limitation for .NET.
Nov 16 '06 #50

94 Replies

This discussion thread is closed

Replies have been disabled for this discussion.