I read this fantastic article this morning, which raises some interesting
points... like, for example, the TREMENDOUS performance advantage of writing
code with using() as opposed to just letting the garbage collection do it's
thing. The author appears to be quite neutral, so this is not a "C# is
better than java" type of post. In fact, he is pretty brutal to C# (that it
apparently deserves) on several points.
Skeet, you ought to love this one. :) http://click.wd-mag.email-publisher....aa2d30b5V7MTb/ 20  6778 
"This article looks at the 'threat' C#/Java has become to C++..."
The "threat" (benefit in using C# over other language) was never in
performance to begin with (although his benchmarks seem pretty good for C#).
As far as the using statement, he didn't understand how to Dispose an object
correctly. If an object has a Dispose method (and most likely has a
Finalizer) then it's VERY important to call the Dispose method, period. The
using statement does that for us. If you don't use it, you need to call
Dispose. This applies to object with a Finalizer, even if it has no
unmanaged resources. He shouldn't be benchmarking these features if he
doesn't understand them. Later he talks about the GC time (apparently
showing that using helps). Well, if you call Dispose and that does the
SuppressFinalize, then you get objects collected much faster (since they get
collected in one collection instead of needing 2). This of course has
performance issues, but only if you code incorrectly. His statements of
saying that it requires the users to understand things very well is not
true. Just calling Dispose (or Close) on a class is enough. Don't see what
the big deal is.
Overall, I get the feeling that C# is kicking butt (considering he's
comparing the first release of C#).
-mike
MVP
"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:Oz**************@TK2MSFTNGP09.phx.gbl... I read this fantastic article this morning, which raises some interesting
points... like, for example, the TREMENDOUS performance advantage of
writing code with using() as opposed to just letting the garbage collection do
it's thing. The author appears to be quite neutral, so this is not a "C# is
better than java" type of post. In fact, he is pretty brutal to C# (that
it apparently deserves) on several points.
Skeet, you ought to love this one. :)
http://click.wd-mag.email-publisher....aa2d30b5V7MTb/
"Michael Giagnocavo [MVP]" <mg*******@Atrevido.net> wrote in message
news:eT**************@TK2MSFTNGP09.phx.gbl... "This article looks at the 'threat' C#/Java has become to C++..."
The "threat" (benefit in using C# over other language) was never in
performance to begin with (although his benchmarks seem pretty good for
C#).
No, but the "threat" would be mitigated by a percieved performance weakness
in C#. That certainly was one of the plagues of VB6 - no "serious"
programmer would consider it for a "real" application, right?
As far as the using statement, he didn't understand how to Dispose an
object correctly. If an object has a Dispose method (and most likely has a
Finalizer) then it's VERY important to call the Dispose method, period.
The using statement does that for us. If you don't use it, you need to call
Dispose. This applies to object with a Finalizer, even if it has no
unmanaged resources. He shouldn't be benchmarking these features if he
doesn't understand them. Later he talks about the GC time (apparently
showing that using helps). Well, if you call Dispose and that does the
SuppressFinalize, then you get objects collected much faster (since they
get collected in one collection instead of needing 2). This of course has
performance issues, but only if you code incorrectly. His statements of
saying that it requires the users to understand things very well is not
true. Just calling Dispose (or Close) on a class is enough. Don't see
what the big deal is.
I think he makes it quite clear that having to know if you CAN call Dispose
is the big deal in his opinion.
You sure took this point differently than I did. I'll say that I've been to
many many seminars, MSDN cafes, VSLive!, etc. and have never heard a single
speaker, Microsoft employee or otherwise, say calling Dispose on every class
you can is "VERY important". In fact, what I've heard preached over and
over is "forget about it" because the GC will watch your back. Yes,
everyone preaches close close close (in try/finally blocks) on resources
like file or database connections but that's a different thing, isn't it?
Now granted, I'm fairly ignorant in regards to the technical details of
Dispose() and Finalize() and GC - but I think that's the point. Someone
like me has been led to believe I don't have to worry about much because GC
is such a beautiful thing, and that's not necessarily the case. I say not
necessarily, because of course we're talking about a certain type of
application where it would even matter to a significant. That is, many
business simply don't have to consider a scenario of creating millions of
objects as fast as they can.
Overall, I get the feeling that C# is kicking butt (considering he's
comparing the first release of C#).
Indeed.
BTW, what kind of guy writes a language like D in his spare time? :)
I also thought things like the string concatenation results were very
interesting. I think the general attitude of C# developers tends to be anal
about using stringbuilder instead of successive concatenations, for example,
but the test results show the performance hit isn't really that bad.
Here's an example of what I was talking about straight from the
documentation:
"Automatic memory management is one of the services that the common language
runtime provides during Managed Execution. The common language runtime's
garbage collector manages the allocation and release of memory for an
application. For developers, this means that you do not have to write code
to perform memory management tasks when you develop managed applications.
Automatic memory management can eliminate common problems, such as
forgetting to free an object and causing a memory leak, or attempting to
access memory for an object that has already been freed."
> > The "threat" (benefit in using C# over other language) was never in performance to begin with (although his benchmarks seem pretty good for C#).
No, but the "threat" would be mitigated by a percieved performance
weakness in C#. That certainly was one of the plagues of VB6 - no "serious"
programmer would consider it for a "real" application, right?
Was that sarcastic? VB6 has HUGE usage for very serious and real purposes.
Maybe not D3D games or rendering engines or office, but many many business
apps run on VB6.
I think he makes it quite clear that having to know if you CAN call
Dispose is the big deal in his opinion.
Well, I guess it just depends on how hard he thinks finding out if a Close
or Dispose method is. In VS.NET, this is trivial. I suppose it might be
harder in emacs (you gotta go read... the docs!).
You sure took this point differently than I did. I'll say that I've been
to many many seminars, MSDN cafes, VSLive!, etc. and have never heard a
single speaker, Microsoft employee or otherwise, say calling Dispose on every
class you can is "VERY important". In fact, what I've heard preached over and
over is "forget about it" because the GC will watch your back. Yes,
everyone preaches close close close (in try/finally blocks) on resources
like file or database connections but that's a different thing, isn't it?
The GC will handle things. It cleans up *managed memory*. It will also
call the finalizers for you so technically, you don't need to call Dispose,
because *eventually* it'll do that when the managed memory requirements for
a GC are hit. The doc quote you posted is referring to this.
The reason I say it's VERY important is because if an object is finalizable,
that means it takes two GCs to collect it. After it's no longer accessible,
then it's collected, but kept around for it's finalizer to be run. After
the finalizer is run, then it's not longer on the finalizequeue. Then there
are *no* roots to it, and it can be freed. Thus, you'll incur many more
GCs, due to the fact that these objects are staying around for much longer
than needed. This is regardless if there are unmanaged resources, since any
finalizable object will get put on the finalize queue.
In his test, he created a situation that was crafted to break. Then he
seems to say that "using" is the only way around this. No, if he is using
an IDisposable, he should dispose it. He was smart enough to figure out
which objects could go in the using statement, so how hard is it to just
call Dispose when you're done?
-mike
MVP
"Michael Giagnocavo [MVP]" <mg*******@Atrevido.net> wrote in message
news:%2******************@TK2MSFTNGP09.phx.gbl... Was that sarcastic? VB6 has HUGE usage for very serious and real
purposes. Maybe not D3D games or rendering engines or office, but many many business
apps run on VB6.
Yes, of course. But as you point out in certain circles VB6 was easily (and
validly) dismissed because of performance issues alone, so performance does
affect the threat level, even though it may not be the basis of the threat
in the first place. That's all, not trying to argue.
The reason I say it's VERY important is because if an object is
finalizable, that means it takes two GCs to collect it. After it's no longer
accessible, then it's collected, but kept around for it's finalizer to be run. After
the finalizer is run, then it's not longer on the finalizequeue. Then
there are *no* roots to it, and it can be freed. Thus, you'll incur many more
GCs, due to the fact that these objects are staying around for much longer
than needed. This is regardless if there are unmanaged resources, since
any finalizable object will get put on the finalize queue.
Yes, I understand all that reasonably well I think. My point is that I have
only very recently started to hear about the importance of using(), etc. and
it's not from Microsoft types. The marketing-speech, and even the
documentation, is talking about .NET was how great GC was because you just
simply didn't have to worry about those pesty details.
And I think that's still true enough for many business applications, just as
VB6 was good enough for them, as you point out. Probably only in an
application where performance is extremely critical or the expected scaleout
is quite large (same thing?) does it significantly matter.
In his test, he created a situation that was crafted to break. Then he
seems to say that "using" is the only way around this. No, if he is using
an IDisposable, he should dispose it. He was smart enough to figure out
which objects could go in the using statement, so how hard is it to just
call Dispose when you're done?
I just now realized that when writing "using(ObjectA)" that ObjectA must
implement IDisposable, so your points are spot on. His statement/argument
doesn't make a whole lot of sense. I had assumed that using() would just
figure out what it should do (or not).
> Yes, I understand all that reasonably well I think. My point is that I
have only very recently started to hear about the importance of using(), etc.
and it's not from Microsoft types. The marketing-speech, and even the
documentation, is talking about .NET was how great GC was because you just
simply didn't have to worry about those pesty details.
Can you point me to some docs that say Dispose/Close is completely
unnecesary (details so I can find it in the MSDN library)? I'd like to file
some bugs.
Thanks,
-mike
Daniel, "Automatic memory management is one of the services that the common language
runtime provides during Managed Execution. The common language runtime's
garbage collector manages the allocation and release of memory for an
application. For developers, this means that you do not have to write code
to perform memory management tasks when you develop managed applications.
Automatic memory management can eliminate common problems, such as
forgetting to free an object and causing a memory leak, or attempting to
access memory for an object that has already been freed."
How true. Note however, that this statement is only about *memory*
management. Finalize() (written as destructor in C#) and Dispose() are
about *resource* management.
When you scan through the .NET framework you'll find 4 different types
of classes implementing IDisposable:
1. Classes where cleanup affects more than one object with a
finalizer, e.g. StreamWriter (A StreamWriter object internally holds a
reference to a Stream object and both have a finalizer).
2. Classes representing non-shareable resources, e.g. FileStream
3. Classes representing resources that are limited by other factors
than memory, e.g. Icon (the number of Icons an AppDomain can create
seems to be limited to ~5000).
4. Others implement it to put the object in a state where it is no
longer used, e.g. MemoryStream.Dispose() marks the stream as closed
but does nothing else.
a. When you fail to call Dispose() (or any other method that cleans up
like e.g. Close()) on objects of classes similar to 1, you are
guaranteed to lose data. This is because the finalization order of no
longer accessible objects is not defined in .NET. Consequently
StreamWriter.~StreamWriter cannot access the Stream object because its
finalizer might have run already.
b. When you fail to call Dispose() on an object similar to 2, you will
*often* run into a problem. I.e. when you try to use the resource
again later. E.g. create a FileStream object, write to the file and
let the object go out of scope. A few seconds later try to do the same
again. Unless you've been very lucky (i.e. the GC has run in the mean
time), the second attempt will fail, as the first object is still
sticking around having a write lock on the file.
c. When you fail to call Dispose() on objects similar to 3, you will
*sometimes* run into problems. I.e. when you use a large enough number
simultaneously and have a high create/throw-away rate.
d. When you fail to call Dispose() on objects similar to 4, you'll
almost never run into problems.
If you want your code do the right thing you have two strategies:
A. Always call Dispose() on objects implementing IDisposable
B. Check documentation what kind of class you have (1 .. 4) and call
Dispose only if necessary
You decide what's best ;-) ...
Regards,
Andreas
P.S. I personally went from A to B and back to A (and I think I stick
with A for the rest of my carreer). The last move is due to a
discussion with John Skeet followed by a deep of research into the
subject.
"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message news:<ey**************@TK2MSFTNGP10.phx.gbl>... Here's an example of what I was talking about straight from the
documentation:
"Automatic memory management is one of the services that the common language
runtime provides during Managed Execution. The common language runtime's
garbage collector manages the allocation and release of memory for an
application. For developers, this means that you do not have to write code
to perform memory management tasks when you develop managed applications.
Automatic memory management can eliminate common problems, such as
forgetting to free an object and causing a memory leak, or attempting to
access memory for an object that has already been freed."
Ha ha ha. My experience is that memory management in C# is extremely
tricky, much trickier than memory management of C++ applications. I
have found several obscure ways for things to go wrong. For example,
closing a form disposes it, and you will get an exception if some
timer callback attempts to manipulate the controls of a closed form.
Also, some Windows.Forms controls are registered in some internal data
structure, and will never be garbage collected unless explicitly
disposed, which means that any form that contains them will never be
garbage collected, nor will any data used by the form, and so on...
You could argue that these are library issues and not language issues,
but it's all the same to me. The result is that effective C#
programming requires a lot of arcane knowledge.
"Andreas Huber" <ah****@gmx.net> wrote in message
news:3e**************************@posting.google.c om...
How true. Note however, that this statement is only about *memory*
management. Finalize() (written as destructor in C#) and Dispose() are
about *resource* management.
Hmm... good distinction that I didn't detect through my newbie colored
glasses.
Why then is Dispose() so necessary if I am very anal about closing
resources. I mean if I write all my file, database, etc. in try/finally
blocks and .Close() everything has that done a lot to mitigate the Dispose()
need or is it something different? Talking about your type 2 (and maybe 1)
below, of course.
When you scan through the .NET framework you'll find 4 different types
of classes implementing IDisposable:
1. Classes where cleanup affects more than one object with a
finalizer, e.g. StreamWriter (A StreamWriter object internally holds a
reference to a Stream object and both have a finalizer).
2. Classes representing non-shareable resources, e.g. FileStream
3. Classes representing resources that are limited by other factors
than memory, e.g. Icon (the number of Icons an AppDomain can create
seems to be limited to ~5000).
4. Others implement it to put the object in a state where it is no
longer used, e.g. MemoryStream.Dispose() marks the stream as closed
but does nothing else.
I think the idea was for *clients* of your code to have an easy formalism to
remember that would accomplish the clean-up after the object was no longer
needed. Ideally, the documentation would specify that Dispose needs to be
called (although just the presence of the method should be enough to suggest
that). Once folk get used to seeing the same discipline across classes
authored by various sources it should become natural for users to invoke
Dispose.
"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:OD***************@TK2MSFTNGP11.phx.gbl...
"Andreas Huber" <ah****@gmx.net> wrote in message
news:3e**************************@posting.google.c om...
How true. Note however, that this statement is only about *memory*
management. Finalize() (written as destructor in C#) and Dispose() are
about *resource* management.
Hmm... good distinction that I didn't detect through my newbie colored
glasses.
Why then is Dispose() so necessary if I am very anal about closing
resources. I mean if I write all my file, database, etc. in try/finally
blocks and .Close() everything has that done a lot to mitigate the
Dispose() need or is it something different? Talking about your type 2 (and maybe
1) below, of course.
When you scan through the .NET framework you'll find 4 different types
of classes implementing IDisposable:
1. Classes where cleanup affects more than one object with a
finalizer, e.g. StreamWriter (A StreamWriter object internally holds a
reference to a Stream object and both have a finalizer).
2. Classes representing non-shareable resources, e.g. FileStream
3. Classes representing resources that are limited by other factors
than memory, e.g. Icon (the number of Icons an AppDomain can create
seems to be limited to ~5000).
4. Others implement it to put the object in a state where it is no
longer used, e.g. MemoryStream.Dispose() marks the stream as closed
but does nothing else.
"Fred Mellender" <no****************@frontiernet.net> wrote in message
news:N_****************@news01.roc.ny... I think the idea was for *clients* of your code to have an easy formalism
to remember that would accomplish the clean-up after the object was no longer
needed. Ideally, the documentation would specify that Dispose needs to
be called (although just the presence of the method should be enough to
suggest that). Once folk get used to seeing the same discipline across classes
authored by various sources it should become natural for users to invoke
Dispose.
Not to mention that it allows language features like foreach(if your
IEnumerator is disposable, it will dispose it) and using to properly clean
up. A standard interface was needed, as to why they choise IDisposable and
Dispose is a question to ask others, but a standard way of doing it is
important.
"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
news:OD***************@TK2MSFTNGP11.phx.gbl...
"Andreas Huber" <ah****@gmx.net> wrote in message
news:3e**************************@posting.google.c om...
How true. Note however, that this statement is only about *memory*
management. Finalize() (written as destructor in C#) and Dispose() are
about *resource* management.
Hmm... good distinction that I didn't detect through my newbie colored
glasses.
Why then is Dispose() so necessary if I am very anal about closing
resources. I mean if I write all my file, database, etc. in try/finally
blocks and .Close() everything has that done a lot to mitigate the
Dispose() need or is it something different? Talking about your type 2 (and maybe
1) below, of course.
When you scan through the .NET framework you'll find 4 different types
of classes implementing IDisposable:
1. Classes where cleanup affects more than one object with a
finalizer, e.g. StreamWriter (A StreamWriter object internally holds a
reference to a Stream object and both have a finalizer).
2. Classes representing non-shareable resources, e.g. FileStream
3. Classes representing resources that are limited by other factors
than memory, e.g. Icon (the number of Icons an AppDomain can create
seems to be limited to ~5000).
4. Others implement it to put the object in a state where it is no
longer used, e.g. MemoryStream.Dispose() marks the stream as closed
but does nothing else.
Kevin Cline <kc******@hotmail.com> wrote:
<snip> You could argue that these are library issues and not language issues,
but it's all the same to me. The result is that effective C#
programming requires a lot of arcane knowledge.
Not really - you dispose everything that implements IDisposable (such
as Form) when you're certain it's not needed any more. Anything that
doesn't implement IDisposable, you assume you don't need to worry
about. I haven't seen many cases that doesn't cover.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
> Why then is Dispose() so necessary if I am very anal about closing resources. I mean if I write all my file, database, etc. in try/finally
blocks and .Close() everything has that done a lot to mitigate the Dispose()
need or is it something different? Talking about your type 2 (and maybe 1)
below, of course.
Close() and Dispose() do exactly the same in all classes I am aware of
so just having Dispose() would be enough. However, for historical
reasons it would confuse people in some cases. E.g. many consider it
unnatural not to have a .Close() function on a FileStream.
I personally only use using-blocks, even inside Dispose(). I.e. a
typical Dispose function of mine looks as follows:
class SomeClass : IDisposable
{
FileStream stream = new FileStream( /* ... */ );
// ...
public void Dispose()
{
using ( stream ) {}
}
}
The using block is equivalent to the following:
if ( stream != null )
{
stream.Dispose();
}
So this saves me some typing. The only place where you can't use using
is when you call the base implementation of Dispose(), as follows:
class A : IDisposable
{
public void Dispose() { /* ... */ }
// ...
}
class B : A
{
public override void Dispose()
{
try
{
// ...
}
finally
{
base.Dispose();
}
}
}
--
Eric Gunnerson
Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/
This posting is provided "AS IS" with no warranties, and confers no rights.
"Andreas Huber" <ah****@gmx.net> wrote in message
news:3e**************************@posting.google.c om... Why then is Dispose() so necessary if I am very anal about closing
resources. I mean if I write all my file, database, etc. in try/finally
blocks and .Close() everything has that done a lot to mitigate the
Dispose() need or is it something different? Talking about your type 2 (and maybe
1) below, of course.
Close() and Dispose() do exactly the same in all classes I am aware of
so just having Dispose() would be enough. However, for historical
reasons it would confuse people in some cases. E.g. many consider it
unnatural not to have a .Close() function on a FileStream.
Typically, such classes define Close(), but then implement IDisposable
explicitly to do the same thing as Close().
On 21 Nov 2003 05:28:27 -0800, ah****@gmx.net (Andreas Huber) wrote: Close() and Dispose() do exactly the same in all classes I am aware of
so just having Dispose() would be enough. However, for historical
reasons it would confuse people in some cases. E.g. many consider it
unnatural not to have a .Close() function on a FileStream.
So, are you saying that when using FileStream objects, you should call
stream.Dispose() instead of stream.Close() after you are finished using it?
From that, I take it that the close of the file actually comes when you close
your binaryReader/Writer object. Is that right or am I missing something?
I come from the Delphi world where you always dispose of objects and free memory
structures that you have allocated on the heap. :)
> >Close() and Dispose() do exactly the same in all classes I am aware of so just having Dispose() would be enough. However, for historical
reasons it would confuse people in some cases. E.g. many consider it
unnatural not to have a .Close() function on a FileStream.
So, are you saying that when using FileStream objects, you should call
stream.Dispose() instead of stream.Close() after you are finished using
it? From that, I take it that the close of the file actually comes when you
close your binaryReader/Writer object. Is that right or am I missing something?
I come from the Delphi world where you always dispose of objects and free
memory structures that you have allocated on the heap. :)
As I understand it, Close() does the same as Dispose() but is provided
because people will first look for a Close() as it is common to close a file
instead of "Disposing" it.
--
cody
[Freeware, Games and Humor] www.deutronium.de.vu || www.deutronium.tk
Kerry, Close() and Dispose() do exactly the same in all classes I am aware of
so just having Dispose() would be enough. However, for historical
reasons it would confuse people in some cases. E.g. many consider it
unnatural not to have a .Close() function on a FileStream.
So, are you saying that when using FileStream objects, you should call
stream.Dispose() instead of stream.Close() after you are finished using it?
Using either Close() or Dispose() is fine as long as you put these
calls in a finally block. Some people prefer to see Close() for
classes that define this method, others prefer to use Dispose() (or
using blocks) throughout.
As I said, I think using using-blocks throughout your code is the most
elegant solution.
However, because Dispose(), Close() and using lead to equally correct
code I don't think this is something worth having extensive arguments
over.
From that, I take it that the close of the file actually comes when you close
your binaryReader/Writer object. Is that right or am I missing something?
Correct. You only need to call Dispose() on the BinaryWriter object,
the underlying Stream is closed automatically.
Regards,
Andreas
Ok, should I find that I rarely need to implement IDisposable myself?
That's part of what I meant by my original question regarding using
..Close().
To rephrase, if I am very careful to use one of these three methods within
my class in the highest finally block on all objects that support
IDisposable, is it necessary to extend the IDisposable to MY class, which in
the context we're discussing would lead the developer using it to think he
must call my Close()?
I would think not. Am I understanding that part clearly?
"Eric Gunnerson [MS]" <er****@online.microsoft.com> wrote in message
news:eW**************@TK2MSFTNGP12.phx.gbl... Close() and Dispose() do exactly the same in all classes I am aware of
so just having Dispose() would be enough. However, for historical
reasons it would confuse people in some cases. E.g. many consider it
unnatural not to have a .Close() function on a FileStream.
Typically, such classes define Close(), but then implement IDisposable
explicitly to do the same thing as Close().
Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote: Ok, should I find that I rarely need to implement IDisposable myself?
Yes.
That's part of what I meant by my original question regarding using
.Close().
To rephrase, if I am very careful to use one of these three methods within
my class in the highest finally block on all objects that support
IDisposable, is it necessary to extend the IDisposable to MY class, which in
the context we're discussing would lead the developer using it to think he
must call my Close()?
I would think not. Am I understanding that part clearly?
It's only *usually* necessary to implement IDisposable if:
o One of your instance variables is something that implements
IDisposable
o One of your instance variables represents an unmanaged resource
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Ok, whew, that makes perfect sense. And those are very concise guidelines
to remember. Thanks.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
It's only *usually* necessary to implement IDisposable if:
o One of your instance variables is something that implements
IDisposable
o One of your instance variables represents an unmanaged resource
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: jmoy |
last post by:
I am a C programmer graduating to C++. As an exercise I wrote a
program to count the number of times that different words occur in a
text file. Though a hash table might have been a better choice,...
|
by: Gaurav |
last post by:
http://www.sys-con.com/story/print.cfm?storyid=45250
Any comments?
Thanks
Gaurav
|
by: Alex Gerdemann |
last post by:
Hello,
I have spent a bunch of time converting a Java program I wrote to C++ in
order to improve performance, and have found that it is not necessarily
faster.
Specifically, I'm writing a...
|
by: twkelsey |
last post by:
Hi,
My company has a scenario where we would like to change the data type
of an existing primary key from an integer to a char, but we are
concerned about the performance implications of doing...
|
by: vj |
last post by:
Please advice me with a few comparison facts of SQL Procedures and
External Procedures ( c or java ) .
-Vj
|
by: Greg |
last post by:
1. What work is in progress to bring C# performance closer to C++/CLI? Can we
expect C# to equal C++/CLI performance? If so when?
2. Also what work is in progress to improve MSIL/CLR/JIT...
|
by: Steven D'Aprano |
last post by:
I'm writing a class that implements rich comparisons, and I find myself
writing a lot of very similar code. If the calculation is short and
simple, I do something like this:
class Parrot:
def...
|
by: Otto Carl Marte |
last post by:
I have noticed an incredible difference in performance between DB2 LUW
v8.2.5 and V9.1.1 with regards to CLOBs.
I will sketch the scenario i have tested.
I created a table with 1 Integer column,...
|
by: yu_kuo |
last post by:
Is there any comparison data on perfomance difference between
std::string and c style string? Or maybe if there are source code
which could be used to measuer on different compiler/platform, in a...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| | |
