CString - high CPU usage
-
Hello, I have a class that logs string information into text files. I do a lot of string operations (using CString) and there are several instances of my class running in the same time. Everything works fine excepting high CPU usage which goes up to 70 – 80 percent when 100-150 instances are running. The final version of the project will require 300-400 instances running and the CPU usage should be as low as possible. If anyone can suggest me a CString replacement that will reduce the CPU usage, I would highly appreciate it. Thanks, Dan.
-
Hello, I have a class that logs string information into text files. I do a lot of string operations (using CString) and there are several instances of my class running in the same time. Everything works fine excepting high CPU usage which goes up to 70 – 80 percent when 100-150 instances are running. The final version of the project will require 300-400 instances running and the CPU usage should be as low as possible. If anyone can suggest me a CString replacement that will reduce the CPU usage, I would highly appreciate it. Thanks, Dan.
First, see if you really have to use
CString
at all... It is far too easy to get into the habit of abusingCString
objects because so many developers are too familiar with them. If you really do need to use a string object, you can try to reduce the number of allocate/deallocate cycles by keeping them around (i.e. do not cause creation ofCString
objects). Preallocating space into them when they are first created may also improve performance. See theCString::GetBufferSetLength(...)
function for more info. For most logging applications, you rarely need to log all that much data. For example, aCString
can hold easily hold more than 1 megabyte of data, but you will rarely be logging that much in a single call. If you have a maximum logging amount, something like 4, 8, 16 or even 32KB, you can easily use a stack-based buffer for something as small as that. This will significantly improve logging performance. If you are logging large (>=4KB) amounts of data and usingCString::Format(...)
you are really wasting time due to the wayCString::Format(...)
works. You are much better off managing your own memory or sticking to stack-based buffers and a function like::_sntprintf(...)
. Peace!-=- James
Please rate this message - let me know if I helped or not! * * *
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles -
Hello, I have a class that logs string information into text files. I do a lot of string operations (using CString) and there are several instances of my class running in the same time. Everything works fine excepting high CPU usage which goes up to 70 – 80 percent when 100-150 instances are running. The final version of the project will require 300-400 instances running and the CPU usage should be as low as possible. If anyone can suggest me a CString replacement that will reduce the CPU usage, I would highly appreciate it. Thanks, Dan.
IMO, avoid using all forms of (xxx)printf, including CString.Format. I once hand-optimized a loop for writing magnetic tapes. I managed to decrease the processing time (for 1000000 simulated tape writes) from 21 seconds to 4. Just by replacing one sprintf statement with a number of strcat(), strcpy(), itoa() e.t.c A that time, I realized the cost (performancewise) of using (xx)printf. And as James R. Twine said, avoid memory allocations.
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
-
Hello, I have a class that logs string information into text files. I do a lot of string operations (using CString) and there are several instances of my class running in the same time. Everything works fine excepting high CPU usage which goes up to 70 – 80 percent when 100-150 instances are running. The final version of the project will require 300-400 instances running and the CPU usage should be as low as possible. If anyone can suggest me a CString replacement that will reduce the CPU usage, I would highly appreciate it. Thanks, Dan.
Preallocation, as James has already been mentioned, will greatly improve the performance. You might also consider using
string
instead ofCString
.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
-
Preallocation, as James has already been mentioned, will greatly improve the performance. You might also consider using
string
instead ofCString
.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
DavidCrow wrote:
You might also consider using
string
instead ofCString
Is
string
actually faster? Do you know of any benchmark results? I've got a couple classes in an application that useCString
heavily, and wonder ifstring
would improve their performance.
Software Zen:
delete this;
-
DavidCrow wrote:
You might also consider using
string
instead ofCString
Is
string
actually faster? Do you know of any benchmark results? I've got a couple classes in an application that useCString
heavily, and wonder ifstring
would improve their performance.
Software Zen:
delete this;
Gary R. Wheeler wrote:
Do you know of any benchmark results?
Nothing scientific, just empirical testing.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
-
DavidCrow wrote:
You might also consider using
string
instead ofCString
Is
string
actually faster? Do you know of any benchmark results? I've got a couple classes in an application that useCString
heavily, and wonder ifstring
would improve their performance.
Software Zen:
delete this;
Gary R. Wheeler wrote:
Is string actually faster? Do you know of any benchmark results? I've got a couple classes in an application that use CString heavily, and wonder if string would improve their performance.
The memory allocation schemes are different between the two. I believe (but I could be wrong) that the
std::string
object allocates likestd::vector
does - that is, it doubles each time. 8 characters, then 16 characters, then 32 characters, etc.CString
on the other hand, basically only allocates what it needs. In MFC 6.0 release mode,CString
will use theCPlex*
allocators which allocate memory in fixed sized chunks, so that if you keep appending smaller strings or single characters to aCString
it may not have to reallocate each time.std::string
can have its reference counting turned off (or it may be by default in some implementations), which may increase its performance a bit. I guess it would depend on the usage of the string object. If you are simply using them as replacements for a manually managedchar
buffer, and are not doing anything really specific to a string object with it, you may not notice much difference. If you build strings through constant append operations, you may notice a difference. If using a multithreaded VC++ 6.0 app, you can customize the allocator used forstd::string
much easier thanCString
, which will allow you to help mitigate heap contention between threads. (Which can be a big hit ifCString
abuse is high.) :P IMHO, the best way you can increaseCString
performance is to avoid it entirely! :P Peace!-=- James
Please rate this message - let me know if I helped or not! * * *
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles -
Gary R. Wheeler wrote:
Is string actually faster? Do you know of any benchmark results? I've got a couple classes in an application that use CString heavily, and wonder if string would improve their performance.
The memory allocation schemes are different between the two. I believe (but I could be wrong) that the
std::string
object allocates likestd::vector
does - that is, it doubles each time. 8 characters, then 16 characters, then 32 characters, etc.CString
on the other hand, basically only allocates what it needs. In MFC 6.0 release mode,CString
will use theCPlex*
allocators which allocate memory in fixed sized chunks, so that if you keep appending smaller strings or single characters to aCString
it may not have to reallocate each time.std::string
can have its reference counting turned off (or it may be by default in some implementations), which may increase its performance a bit. I guess it would depend on the usage of the string object. If you are simply using them as replacements for a manually managedchar
buffer, and are not doing anything really specific to a string object with it, you may not notice much difference. If you build strings through constant append operations, you may notice a difference. If using a multithreaded VC++ 6.0 app, you can customize the allocator used forstd::string
much easier thanCString
, which will allow you to help mitigate heap contention between threads. (Which can be a big hit ifCString
abuse is high.) :P IMHO, the best way you can increaseCString
performance is to avoid it entirely! :P Peace!-=- James
Please rate this message - let me know if I helped or not! * * *
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFilesJames R. Twine wrote:
std::string can have its reference counting turned off (or it may be by default in some implementations), which may increase its performance a bit.
See the comparison in http://www.codeproject.com/string/fix_str.asp[^]
-
James R. Twine wrote:
std::string can have its reference counting turned off (or it may be by default in some implementations), which may increase its performance a bit.
See the comparison in http://www.codeproject.com/string/fix_str.asp[^]
Unless I am missing something, I am not seeing a good comparison there. I see a few mentions of the words "fast" and "slow" but nothing that shows exactly how fast or slow something is. Something has to be faster or slower than another. Peace!
-=- James
Please rate this message - let me know if I helped or not! * * *
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles