It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I have a service, that I query once in a very long while, and i would like to "streamline", or improve the efficiency, of its memory allocation.
Most of the time it just sits and waits, and once in awhile it gets a request that requires allocating a lot of memory, and do some processing on it. I don't know the types or structure in advance - it depends on the request, and varies wildly.
Now, the big processing request is precluded by some chatter (other requests), that might take a few seconds.
What I want to do is, when the chatter (smaller requests) start, say to the .Net Framework: go to windows, and get yourself a couple of GB's of memory so it'll be available faster when i ask, and when I'm done, say to the .Net: everything I'm not currently using, you can give back, because I'm not going to need it for a while.
I'm starting profiling as we speak... but I suspect it would be part of the issues that could improve.
I'll try to clarify the situation.
I have a service that sits on a server and 95% of the time just does nothing. Once in a long while it gets a request to do some mostly memory intensive processing.
I know a little bit of time in advance that it's all going to happen.
All i want to do, is hint the GC "Were going to need a lot of memory soon" and later "Were not going to need anything special for a while"
OK.
I've done profiling, and decided I don't care about this.
The allocation does take some time (several to several dozens milliseconds), but it's insignificant versus the rest of the processing...
regarding the releasing part, it happens eventually, and doesn't really interfere with the rest of the server...
If you want to be able to reserve a chunk of memory for your uses then please see:
allocating "unmanaged" memory in c#
Note, doing so can be risky and the Garbage Collector and memory allocation in the .NET VM is already rather good.
If the memory allocation can be largely cached then I'd recommend caching what can be done so with WeakReference such that quick successive requests could benefit from accessing the cached data, but if a garbage collection comes in between requests spaced a decent amount apart then the data can be released and just re-created in the next request.
See: Weak reference benefits
And: http://msdn.microsoft.com/en-gb/library/system.weakreference.aspx
The GC is most of the time smart enough to do this for you. However, it is an architectural problem and can be dealt with by modifying the flow of activities in the service.
e.g. you can allocate the objects required for processing big request in advance before the request comes. However, for deallocating, either explicitly implement idisposible interface to them and destroy them once they are used or leave it to GC.
Further, you have to understand how memory allocation works. In order to get memory allocated for .Net objects, you must be knowing the type of object in advance. Just allocating plain block of memory is in no way helpful to you. Most of the time the object creation or cloning code is more resource consuming compared to the mallocs that the framework uses to allocate memory for the object.
Considering the details, I would say that even if you could successfully do this routine, it would become much more complex and might add few more bugs to your code. Better leave this to .Net framework. It is very good at allocating and deallocating memory.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm writing trading software and I need every single microsecond in speed.
What can I do? I was thinking to use ngen but wikipedia tells that JIT might be even better. What can I tune? May I force it to use Xeon E5 instructions somehow? Will changing priority in Windows to highest help and if so how to run program always with highest priority? May I add this program to "trusted" so .NET will not check security etc.
I.e. I want complete list of configurations in hardware/software/.net and actions (like running ngen) which can affect and help run program faster.
The time comes stop guessing and find where the problem(s) actually are.
Use EQATEC free preformance analyzer to figure out your bottlenecks and fix them.
NGEN is usefull to boost the startup time of the application , but it's definitely not a golden key for that problem. It's most probabble that you will fix it profiling your app.
What about runtime optimization:
checkout DB accesses (if any), optimize your queries and minimize the data retrived to the amount you really need
look on disk access operations
look on CPU consuption. After profiling yoi can use Process Explorer to check CPU and Memory consuption from your application behavioural point of view
after profiling identify unnecessary or heavy iteration you made (if any), and make use of dictionary (just example) for O(1) access
... and more...
Like a literature for reading on performance can suggest definitely the monster blog of one of the greatest performance specialists in IT industry: Rico Mariani's Performance Tidbits
Hope this helps.
Not windows, pick a more real-time focused OS, as speed has several components, consistent speed or best possible?
Tuning code is nice and all, but don't always go for that. Try code reviews, correcting large logical errors or extra work is much more beneficial than low level tuning.
Understand that every microsecond counts, but your CPU and logic are the fastest part, network, disk, paging, etc are more than likely the real enemies. So make sure you are focusing on the right thing. You must stop all I/O which is not needed.
Certain drivers, network cards, etc are faster than others.
Review your use of libraries and make sure you understand their performance aspects, so much run time is within libraries etc.
Sure there are more .NET centric answers and specific ones, but I tried answering the question behind the question.
Eliminate GC!
Another "trick" that people use is in trading systems is to write C# code that does not garbage collect. Obviously it is impossible to remove garbage collection entirely, but what you can do is minimize or eliminate GC once your program is running. You do all the work to setup your app, initialize your components, etc in an initialization phase and allow any GC here. But once you are setup and ready to run, you make sure that the code does not generate garbage and does not perform boxing/unboxing. (Have a search on SO for like "avoid GC" and you will find some useful information).
The term "trading system" can encompass a myriad of different things. Are you talking about writing an algo in .NET? Or is your algo written in something else and there is .NET framework that is hosting it? Are you just talking about the UI? Is your trading system distrubuted? Do you know how fast you program needs to be? If you are not trading a High Frequency model then what is "fast enough"? Don't just push for something that has to operate in the 1-2ms scale when your trading strategy does not need it.
And importantly, don't throw out the tried and trusted OO principles; SOLID still applies to trading systems although you may bend the rules in certain cases. Just make sure that you identify what needs to be performant and optimize that - don't think that you have to optimize everything and make sure you benchmark and measure everything so that you know what needs to be faster and by how much.
And Keep It Simple! A trading system does not have to be complex.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
We have a lot of old legacy Perl scripts that connect to a MS SQL db process some records, and make files. Over time, the daily transaction size grew and these scripts are becoming more and more expensive.
Moreover, the Databases grew with more and more tables, and modifying the old Perl scripts is cumbersome. Was thinking about redoing some of the major scripts under .NET (in C#)
Is there a speed advantage under a machine running Windows Server of using one vs the other?
Again the idea is
Execute Query
Process Results through some basic formatting
Write results to a file
Depends on how stupid the respective programmers are. When initialized properly they both should be comfortable saturating whatever bandwidth you throw at them disc system wise - and THERE is your bottleneck. Make large cached writes (.NET BufferedStream) and make ure you have a SSD or something fast ready. The perforamcne bottleneck with proper programming is the disc subsystem for this type of work.
Both tasks can be done equally fast in either language. They can also both be done horribly wrong and horribly slowly in both languages, so there is that to consider.
From another one of your comments, you mention that you do the formatting on the SQL server side. These queries would potentially be a lot less expensive if you did that on the app side, and then moved this script to a faster machine so as to impact the db server the least.
I'd guess that harddrive speed is your biggest problem now. You should monitor the resources while running this script -- Is it maxing out your cpu? is it reading/writing a lot to memory?(it shouldnt). Is it just waiting on disk i/o most of the time? If it is, you should look into upgrading your storage to either faster disks, a raid, or an ssd depending on what makes the most sense for your situation.
Even just something like defragging the disk might help.
If you have good cpu/memory to spare but cant avoid the slow disk, you could even look into compressing all of the output in memory before writing it (again, assuming this is a good idea, it really depends on where these reports are going and what format is needed).
I don't expect great differences between those languages when it comes to write performance (generally bottleneck will be hard disk, not processing power of CPU) . You should rather take a look on "costs of maintaining code", in C# you can get much cleaner code, not to mention that integration with MS SQL probably will be more efficient, not to mention that you can use threading.
Better Code, more maintainable, maybe faster. Yeah C# is good idea
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
When is it acceptable to call GC.Collect?
Is Using of GC.Collect Method necessary and is it a good practice?
If yes, when should I use this method?
If No, Why?
Edit: Accourding to MSDN What is the meaning of: Use this method to try to reclaim all memory that is inaccessible.
As a general rule... don't use it.
GC.Collect force a collection by the garbage collector, which, among other things, means pausing all the threads of the program so that the garbage collector can verify which objects are no longer referenced and claim the unused memory.
Usually the GC will automatically decide when he should collect memory, considering when your program is idle or if the allocated memory (virtual memory) is getting low so in order to allocate more it needs to free some. In my experience the .NET GC (as in Microsoft) is pretty intelligent and does what it does ratter well. Other GCs (as in mono) I don't have experience with them, but still probably will do a better job than the developer deciding when to perform a collection.
That, of course, has a good impact in performance and, as with many other situations, it knows better than you do the best time to perform a collection (in 99% of the cases that's true). So no, it's not a good practice and you should only do it when you have a really good reason to do it... a deep understanding of what it does and the possible consequences it may have.
Not generally recommended; not generally considered good practice.
In general the GC knows better than you what needs cleaning up, and when. Best practice is to leave the GC alone to do its business unhindered unless you have concrete proof that the GC's strategy is causing problems that can be solved by forcing it to behave differently.
It is usually not necessary, and usually not a good idea to use it.
There are times when you need to use it but usually you are forcing a collect at a not optimal time, which have a performance hit.
There is good discussion on the matter here and here.
I have explained a few things relevant here:
WPF memory leak
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 13 years ago.
Please can anyone one point me to a good tutorial that helps me to make my code fast and light.
I'm interested to know which Method is faster and when to use a method instead of other...
And how to evaluate if a code is good or bad?
My programming language is C#.
Hi all,
Thanks for your replies, they are very helpful.
I'm editing my question to be more specific specially that optimization is unlimited.
I want to know what is the best method in each condition.
For example using StringBuilder is better than string if i am appending lines to a string...
I only need this simple things.
Be aware of sub optimization.
Even though one specific function is faster than another replacing this isn't necessarily gonna make any difference in the runtime of your application. You need to understand which parts of your code that actually is a potential problem, and focus on optimizing these parts. Be aware of the O notation of your functions, and how often they are called. To identify parts that needs optimization a profiler can be of good help.
This question has some interesting points on why you shouldn't optimize until there is actually a need to do so.
Sure. Here's what we do:
Begin the journey by deciding when the journey is over. Set meaningful, customer-focussed, realistic performance goals. (For both speed and resource consumption.)
Carefully test your code frequently to see if you are meeting your performance targets.
If you are meeting your performance targets, don't worry about performance. Things are fine. Worry about bugs, or robustness, or features.
If you are not meeting your performance targets, run a profiler. Use it to identify what is the worst offending code. It only makes sense to fix the worst code; making something that is already incredibly fast and light slightly faster and lighter does not solve your performance problem.
Rewrite the slow code so that it's more performant. (This is the hard bit.) Make sure you test it to make sure it really is better.
If despite your best efforts you cannot make it good enough, either re-evaluate what your goals are, or cancel the project and spend your time on something that you can be successful at.
Keep iterating on that until you ship something.
Basically implement first, then test where to optimize.
If you are using Visual Studio Profissional you can use Analyze -> Launch Performance Wizard to analyze method performance. I am not sure about whether the other versions support this feature, however, there are also some commercial/free applications around ... look for profiler (see here for a list).
Type REALLY fast.
You should look at hidden features of c#, this post covers the most best practises in c# development
You can get a ton on advice of on this. But be aware of :
Premature optimization is root of all evil.
Aim first for correctness, next for clarity and only then performance.
As the old saying goes,
"No one cares how quickly you can calculate the wrong answer"
(on a practical level though, use a profiler)
If one method was always faster than another, they wouldn't bother including the slower one.
The only invariant when it comes to performance is that you need to profile. Everything follows from that.
If you get yourself a profiler, it will help you along, some will even give you great tips.
Example: ANTS Profiler
Usually you will find that reducing the number of times you create Strings to be the main performance boost you can get.
That and not messing with the Garbage Collector manually (unless you really really know what you're doing)
This link for Java design patterns is way too involved, don't get too put off by the word Java there, you can use what they teach for development in any language.
The thing is, if you want to know when to do what and what methods to use and so on, design patterns is what you are talking about.
I wish someone had pointed this to me earlier in my career.
In terms of general advice:
Try to use the fewest loops necessary
Move code out of loops where possible
Avoid copying things (like strings) in loops
Avoid creating objects in loops
Cache where warranted (generally small objects that take a lot of time to make), but make sure your cache has a good disposal policy or it turns into a memory leak
You can compile your program in native mode to improve the runtime performance.
One of the ways of figuring this out yourself is having a console app where you try running discrete pieces of code against each other and timing them. Like here.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
In your actual programming experience, how did this knowledge of STACK and HEAP actually rescue you in real life? Any story from the trenches? Or is this concept good for filling up programming books and good for theory?
The distinction in .NET between the semantics of reference types and value types, is a much more important concept to grasp.
Personally, I have never bothered thinking about the stack or heap in all my years of coding (just CLR based).
To me it is the difference between being a "developer/programmer" and a "craftsman". Anyone can learn to write code and see how things just "magically happen" for you not knowing why/how. To really be valuable at what you do, I think there is a great importance to find out as much as you can about the Framework you're using. Remember it's not just a language, it's a Framework that you leverage to create the best application to your abilities.
I've analyzed many memory dumps over the years and found it extremely helpful knowing the internals and differences between the two. Most of these have been OutOfMemory conditions and unstable applications. This knowledge is absolutely necessary to use WinDbg when looking at dumps. When investigating a memory dump, knowing how memory is allocated between the kernel/user-mode process and the CLR can at least tell you where to begin your analysis.
For example, let's take an OOM case:
The allocated memory you see in the Heap Sizes, Working Set, Private Memory, Shared Memory, Virtual Memory, Committed Memory, Handles, and Threads can be a big indicator of where to start.
There about 8 different heaps that the CLR uses:
Loader Heap: contains CLR structures and the type system
High Frequency Heap: statics, MethodTables, FieldDescs, interface map
Low Frequency Heap: EEClass, ClassLoader and lookup tables
Stub Heap: stubs for CAS, COM wrappers, P/Invoke
Large Object Heap: memory allocations that require more than 85k bytes
GC Heap: user allocated heap memory private to the app
JIT Code Heap: memory allocated by mscoreee (Execution Engine) and the JIT compiler for managed code
Process/Base Heap: interop/unmanaged allocations, native memory, etc
Finding what heap has high allocations can tell me if I have memory fragmentation, managed memory leaks, interop/unmanaged leaks, etc.
Knowing that you have 1MB (on x86)/ 4MB (on x64) of stack space allocated for each thread that your app uses reminds me that if I have 100 threads you will have an additional 100MB of virtual memory usage.
I had a client that had Citrix servers crashing with OutOfMemory problems, being unstable, slow responsiveness when their app was running on it in multiple sessions. After looking at the dump (I didn't have access to the server), I saw that there were over 700 threads being used by that instance of the app! Knowing the thread stack allocation, allowed me to correlate the OOMs were caused by the high thread usage.
In short, because of what I do for my "role", it is invaluable knowledge to have. Of course even if you're not debugging memory dumps it never hurts either!
It certainly is helpful to understand the distinction when one is building compilers.
Here are a few articles I've written about how various issues in memory management impact the design and implementation of the C# language and the CLR:
http://blogs.msdn.com/ericlippert/archive/tags/Memory+Management/default.aspx
I don't think it matters if you're just building average business applications, which I think most .NET programmers are.
The books I've seen just mention stack and heap in passing as if memorizing this fact is something of monumental importance.
Personally, this is one of the very few technical questions that I ask every person I'm going to hire.
I feel that it is critical to understanding how to use the .NET framework (and most other languages). I never hire somebody who doesn't have a clear understanding of memory usage on the stack vs. the heap.
Without understanding this, it's almost impossible to understand the garbage collector, understand .NET performance characteristics, and many other critical development issues.
The important distinction is between reference types and value types. It's not true that "value types go on the stack, reference types go on the heap". Jon Skeet has written about this and so has Eric Lippert.
We had a Claim Entity (business Object) which contained data for an entire claim. One of the requirements of the application was to create an audit trail of every single value changed by the user. In order to this without hitting the database twice we would maintain Original Claim Entity in the form and a Working Claim Entity. The Working Claim Entity would get updated when the user clicked Save and we would then compare the Original Claim Entity properties with corresponding Working Claim Entity properties to determine what changed. One day we noticed hey our compare method is never finding a difference. This is where my understanding of the Stack and Heap saved my rear end (specifically value types vs reference types). Because we needed to maintain to copies of the same object in memory the developer simply created two objects
Dim originalClaim As ClaimBE
Dim workingClaim As ClaimBE
then called the business layer method to return the claim object and assigned the same claimBE to both variables
originalClaim = BLL.GetClaim()
workingClaim = originalClaim
hence two reference types pointing to the same value type. Nightmare averted.