dataset Performence Issue

[Cor Ligthert [MVP]]

Thats it !! Frans has argued in my favor, all other arguments laid to rest

I agree man, Native Code is faster than Managed in most circumstances
(atleast today).

As almost forever you should really read with what phrase from you started
this discussion.

Managed Code can never be as fast and as optimized as native code.

I did not see that Frans did agree that with you or I should understand him
completely wrong. In my opinion told he the opposite.

Cor

 

[Sahil Malik [MVP]]

You're wrong.

--

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx

 

[William \(Bill\) Vaughn]

Ah, worrying about JIT vs native code is all too often a meaningless
exercise. Consider that applications spend most of their time waiting.
Waiting for disks, video retrace, waiting for the server to answer a (dumb)
question, waiting for the net to respond and (most of all) waiting for the
user to come back from lunch.



--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

Maybe in very specific situations it can be. Maybe in future the
balance will tip, but in general native code is faster, don't you
think?

Managed code has the overhead of the CLR and JIT which consume cpu
time. native code doesn't have that. On the other hand, native code
lacks information about code usage at runtime. This means that it has
to perform compile-time optimization and hope for the best at runtime.
In theory, you can argue that a JIT can produce faster code at runtime
because it knows the code usage patterns and can therefore decide some
code path is faster, based on information available only at runtime.
native code doesn't have that, which can lead to slower code.

That is, in theory. Deciding what's faster eats time too, and the more
time spend on deciding what's faster, the less time is gained.

Another optimization trick for managed code is that it performs code
analysis at compile time like native compilers do, and instead of
optimizing the code in full, it places JIT hints into the IL, so at
runtime the JIT will be faster in deciding what to do, as it knows up
front what lays ahead (because that's already analysed at compile
time). I believe sun's hotspot system uses these.

MS research has said that within a few years time, managed code is
faster than native code. That is to be seen though. A lot is needed in
the JIT department to get everything as fast as it should be.

FB

Actually, managed code can be faster than native code due to CPU
specific optimisations.
Perhaps now there aren't many optiomizations compiler does, however
in future we should se more of them.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info

Managed Code can never be as fast and as optimized as native code.

Why not?

I have the idea about the opposite.

I make it short otherwise you probably don't understand the

question.

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Frans Bouma [C# MVP]]

Thats it !! Frans has argued in my favor, all other arguments laid to
rest

LOL

FB

I agree man, Native Code is faster than Managed in most circumstances
(atleast today).

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
----------------------------------------------------------------------
------

Maybe in very specific situations it can be. Maybe in future the
balance will tip, but in general native code is faster, don't you
think?

Managed code has the overhead of the CLR and JIT which consume cpu
time. native code doesn't have that. On the other hand, native code
lacks information about code usage at runtime. This means that it
has to perform compile-time optimization and hope for the best at
runtime. In theory, you can argue that a JIT can produce faster
code at runtime because it knows the code usage patterns and can
therefore decide some code path is faster, based on information
available only at runtime. native code doesn't have that, which
can lead to slower code.

That is, in theory. Deciding what's faster eats time too, and the
more time spend on deciding what's faster, the less time is gained.

Another optimization trick for managed code is that it performs code
analysis at compile time like native compilers do, and instead of
optimizing the code in full, it places JIT hints into the IL, so at
runtime the JIT will be faster in deciding what to do, as it knows
up front what lays ahead (because that's already analysed at compile
time). I believe sun's hotspot system uses these.

MS research has said that within a few years time, managed code is
faster than native code. That is to be seen though. A lot is needed
in the JIT department to get everything as fast as it should be.

FB

"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
Actually, managed code can be faster than native code due to CPU
specific optimisations.
Perhaps now there aren't many optiomizations compiler does, however >> > in future we should se more of them.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info

Managed Code can never be as fast and as optimized as native code. >> > >
Why not?

I have the idea about the opposite.

I make it short otherwise you probably don't understand the
question.

--

 

[Frans Bouma [C# MVP]]

Ah, worrying about JIT vs native code is all too often a meaningless
exercise. Consider that applications spend most of their time
waiting. Waiting for disks, video retrace, waiting for the server to
answer a (dumb) question, waiting for the net to respond and (most of
all) waiting for the user to come back from lunch.

Hey, I thought you were a real geek!

But seriously, you're right of course, though, when you need the
speed, you want it. Like having a fast machine: typing in code isn't
that CPU intensive, but compiling is. So having a fast machine can be
of great benefit

FB

--

 

[scott.and.kim]

Exactly Bill. Anytime you're hitting the filesystem for ANY reason,
whether you are retrieving rows from an RBDMS or just taking up enough
memory that you cause the system to page more memory, all of those
concerns you have over in-memory performance go out the window. The
filesystem hit will ALWAYS be the slowest part of your system.

 

[Sahil Malik [MVP]]

Well of course, but the original discussion here was "holding a huge data
cache".
I believe that task can be done better in Native code, than in Managed code.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
----------------------------------------------------------------------------
---------------

Ah, worrying about JIT vs native code is all too often a meaningless
exercise. Consider that applications spend most of their time waiting.
Waiting for disks, video retrace, waiting for the server to answer a (dumb)
question, waiting for the net to respond and (most of all) waiting for the
user to come back from lunch.



--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

Maybe in very specific situations it can be. Maybe in future the
balance will tip, but in general native code is faster, don't you
think?

Managed code has the overhead of the CLR and JIT which consume cpu
time. native code doesn't have that. On the other hand, native code
lacks information about code usage at runtime. This means that it has
to perform compile-time optimization and hope for the best at runtime.
In theory, you can argue that a JIT can produce faster code at runtime
because it knows the code usage patterns and can therefore decide some
code path is faster, based on information available only at runtime.
native code doesn't have that, which can lead to slower code.

That is, in theory. Deciding what's faster eats time too, and the more
time spend on deciding what's faster, the less time is gained.

Another optimization trick for managed code is that it performs code
analysis at compile time like native compilers do, and instead of
optimizing the code in full, it places JIT hints into the IL, so at
runtime the JIT will be faster in deciding what to do, as it knows up
front what lays ahead (because that's already analysed at compile
time). I believe sun's hotspot system uses these.

MS research has said that within a few years time, managed code is
faster than native code. That is to be seen though. A lot is needed in
the JIT department to get everything as fast as it should be.

FB

"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
Actually, managed code can be faster than native code due to CPU
specific optimisations.
Perhaps now there aren't many optiomizations compiler does, however
in future we should se more of them.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info

Managed Code can never be as fast and as optimized as native code.

Why not?

I have the idea about the opposite.

I make it short otherwise you probably don't understand the
question.

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[William \(Bill\) Vaughn]

Ah sure... but doing something like holding a giant data cache can also be
construed as a "challenged" approach unless you REALLY need all that data in
memory at once. If you're doing CAD or matrix math you often need to keep a
lot of data in memory and raw processing power is essential. For process
control, complex instrumentation and other CPU-intensive operations HLLs
often don't cut it performance-wise. Ordinary business applications (which
90% of the people we see day-to-day) rarely need to bring the entire data
store into memory. They often try, but there are far more rational ways to
deal with problems than transporting the database to the client and
crunching--or even fetching/filtering/sorting.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

Well of course, but the original discussion here was "holding a huge data
cache".
I believe that task can be done better in Native code, than in Managed
code.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
----------------------------------------------------------------------------
---------------

Ah, worrying about JIT vs native code is all too often a meaningless
exercise. Consider that applications spend most of their time waiting.
Waiting for disks, video retrace, waiting for the server to answer a (dumb)
question, waiting for the net to respond and (most of all) waiting for
the
user to come back from lunch.



--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

Sahil Malik [MVP] wrote:

Maybe in very specific situations it can be. Maybe in future the
balance will tip, but in general native code is faster, don't you
think?

Managed code has the overhead of the CLR and JIT which consume cpu
time. native code doesn't have that. On the other hand, native code
lacks information about code usage at runtime. This means that it has
to perform compile-time optimization and hope for the best at runtime.
In theory, you can argue that a JIT can produce faster code at runtime
because it knows the code usage patterns and can therefore decide some
code path is faster, based on information available only at runtime.
native code doesn't have that, which can lead to slower code.

That is, in theory. Deciding what's faster eats time too, and the more
time spend on deciding what's faster, the less time is gained.

Another optimization trick for managed code is that it performs code
analysis at compile time like native compilers do, and instead of
optimizing the code in full, it places JIT hints into the IL, so at
runtime the JIT will be faster in deciding what to do, as it knows up
front what lays ahead (because that's already analysed at compile
time). I believe sun's hotspot system uses these.

MS research has said that within a few years time, managed code is
faster than native code. That is to be seen though. A lot is needed in
the JIT department to get everything as fast as it should be.

FB


"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
Actually, managed code can be faster than native code due to CPU
specific optimisations.
Perhaps now there aren't many optiomizations compiler does, however
in future we should se more of them.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info

Managed Code can never be as fast and as optimized as native code.

Why not?

I have the idea about the opposite.

I make it short otherwise you probably don't understand the
question.


--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET:
http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Sahil Malik [MVP]]

There are two specific applications I have worked with where it made sense
to keep a huge in-memory cache (and I am SURE if you saw the exact
requirements, you would agree that an in-memory cache was the right
architecture).

One was a popular weather application which sits on people's desktops and
tells you weather for many thousands of locations, continously updated and
the webservice being hit once every few seconds, from every desktop around
the world (many many millions).

The second was for an architecture which had many computers analyzing price
histories for the last 30 years for any financial component.

Those both fall in the 10% that DO need a HUGE in-memory cache.

And yes of course these are exceptions, not the rule.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
----------------------------------------------------------------------------
---------------

Ah sure... but doing something like holding a giant data cache can also be
construed as a "challenged" approach unless you REALLY need all that data in
memory at once. If you're doing CAD or matrix math you often need to keep a
lot of data in memory and raw processing power is essential. For process
control, complex instrumentation and other CPU-intensive operations HLLs
often don't cut it performance-wise. Ordinary business applications (which
90% of the people we see day-to-day) rarely need to bring the entire data
store into memory. They often try, but there are far more rational ways to
deal with problems than transporting the database to the client and
crunching--or even fetching/filtering/sorting.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

Well of course, but the original discussion here was "holding a huge data
cache".
I believe that task can be done better in Native code, than in Managed
code.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
--------------------------------------------------------------------------

--

---------------

Ah, worrying about JIT vs native code is all too often a meaningless
exercise. Consider that applications spend most of their time waiting.
Waiting for disks, video retrace, waiting for the server to answer a (dumb)
question, waiting for the net to respond and (most of all) waiting for
the
user to come back from lunch.



--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

Sahil Malik [MVP] wrote:

Maybe in very specific situations it can be. Maybe in future the
balance will tip, but in general native code is faster, don't you
think?

Managed code has the overhead of the CLR and JIT which consume cpu
time. native code doesn't have that. On the other hand, native code
lacks information about code usage at runtime. This means that it has
to perform compile-time optimization and hope for the best at runtime.
In theory, you can argue that a JIT can produce faster code at runtime
because it knows the code usage patterns and can therefore decide some
code path is faster, based on information available only at runtime.
native code doesn't have that, which can lead to slower code.

That is, in theory. Deciding what's faster eats time too, and the more
time spend on deciding what's faster, the less time is gained.

Another optimization trick for managed code is that it performs code
analysis at compile time like native compilers do, and instead of
optimizing the code in full, it places JIT hints into the IL, so at
runtime the JIT will be faster in deciding what to do, as it knows up
front what lays ahead (because that's already analysed at compile
time). I believe sun's hotspot system uses these.

MS research has said that within a few years time, managed code is
faster than native code. That is to be seen though. A lot is needed in
the JIT department to get everything as fast as it should be.

FB


"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
Actually, managed code can be faster than native code due to CPU
specific optimisations.
Perhaps now there aren't many optiomizations compiler does, however
in future we should se more of them.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
Blog: http://cs.rthand.com/blogs/blog_with_righthand/
SLODUG - Slovene Developer Users Group www.codezone-si.info

Managed Code can never be as fast and as optimized as native code.

Why not?

I have the idea about the opposite.

I make it short otherwise you probably don't understand the
question.


--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET:
http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Sahil Malik [MVP]]

Nigel,

Try measuring the time of "removing" rows from a huge dataset (i.e. lots of
datarows).

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx