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 2 years ago.
Improve this question
I am working on implementing threading to my C# program. Each thread requires access to the same array, but does not need to write to it, only read data. Should this array be deep copied for each thread?
The reason I think this might be important (from my very limited knowledge of threading) is so that threads on different CPU cores can store copies of the array in their own cache instead of constantly requesting data from a single core's cache where the array is stored, but perhaps the compiler or something else will optimise away this inefficiency?
Any insight would be much appreciated.
Since you haven't specified the hardware architecture you are running on I'm going to assume it is either and Intel or AMD x64 processor. In which case I recommend trusting the processor to correctly optimize this situation. By creating multiple copies that the processor that the compiler can't know are duplicate copies you will force the processor to use more memory and spread the available cache space over more memory lessening it's effectiveness.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am reading Concurrency in C# Cookbook and the book told me that:
ConcurrentDictionary<TKey, TValue> is best when you have multiple
threads reading and writing to a shared collection. If the updates are
not constant (if they’re more rare), than ImmutableDictionary<TKey,TValue>
may be a better choice.
I know that Add or Remove a large immutable collection can be slow, and my question is, is there any other difference between them? Now that they are all thread safe, why is ImmutableDictionary a better choice when the updates are not constant?
These two classes ConcurrentDictionary and ImmutableDictionary were compared just because of the simple reason, both are thread safe.
However, it is not a good idea to use ImmutableDictionary for multi-threading. It is designed to represent data which should be loaded once, and shouldn't be changed / modified later on. Any modifications would lead to creating new instance of ImmutableDictionary, which is not really efficient.
Immutable can't be changed, i.e. no add/remove can alter existing dictionary, rather would create a new one shipping all but deleted item. Concurrency proceeds on the lock { } statement which has nothing to do with immutability. Locks are necessary to manage write operations done by more than single thread to the same memory piece (i.e. same object).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
can you please tell me what is better to use?
for-each loop
create new object of class.
In mine case both aspect gave me same output.
so, my question is that what will i prefer to use.
If i choose 1st aspect.
whenever my page load at that time in fore-each loop(50 record fixed) will come.
and every time that loop execute so, my page execution is bit slower.
If i choose 2nd aspect
whenever my page load at that time new object is created and memory initialize
In asp.net mvc any inbuilt function or method to remove garbage collection(collection of unusual object) ?
please tell me what would i prefer for better use with relevant reason.
Write whichever one is simpler to code and more obviously correct. Then, see if your page is too slow or uses too much memory. (You get to decide what "too slow" or "too much" means, it's your application!)
If it works, great! Your problem is solved, work on adding more value to your application in some other way.
If it is too slow or uses too much memory, then try the less simple approach.
Then -- and this is the important part -- measure the difference for your application. Then, and only then, can you know the right answer.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
If I've some common functionality that I've to keep in a class, so will I go for static, sealed or abstract class...Does all these types of classes serve the purpose of keeping the common functionality together...where actually the difference lies when I've to go for one
abstract, sealed, static has nothing to do with real time development. It has to do with bring structure within your software, so that the functionality implemented in classes can and should be used in the right way.
After some comments i think this:
I think you can only learn this, by doing it. There isn't a book or epub that will explain you how to do programming. They will show the syntax and some examples. It will be trial and error. Every day you'll face a new challenge.
You'll have to practice it. The best advise is, look what others already created and try to imagine why did they wrote/solve it that way.
I can explain what a static/sealed/abstract class is/does, but it doesn't learn you when to use it.
Back to the question: Define 'real time'.. I think that static/abstract/sealed should NOT be decisive on how you write your 'real-time' software. If you are 'scared' about performance on this level, C# should not be your choise. I would write c++ or if you want a real challenge, try to beat the compilers with asm ;-)
I think you won't measure the 'overhead'
So, use abstract/static/sealed in a right way, so your future collega's/you can read/maintain it.
I use C# for communication (tcp/ip) between a windows computer and a PLC (with delta robots). But it's far from realtime. It's fast enough to keep many robot working with > 100 messages per second.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am making a game in C# and XNA and will be porting it using MonoGame. I would like to know which is a better option for performance.
Should I write and type out my maps in the code of the game itself, or should I create an XML file and store it in their?
By map I mean the layout of the tile-map. It looks like this if I type it in the code:
map.Generate(new int[,]{
{0,0,0,0,0,0,0,0,0,0,0,0,},
{0,0,0,0,0,0,0,0,0,0,0,0,},
{0,0,0,0,0,0,0,0,0,0,0,0,},
{0,0,0,0,0,0,0,0,0,0,0,0,},
{0,0,0,0,0,0,0,0,0,0,0,0,},
}, 64);
I am new as a programmer and any advice should help?
Thanks, BlazeCrate
There will be neglagable performance difference between the two as no matter which you use they both will end up being stored as some kind of in memory object. The only potential difference in "performance" is how long it will take to make that in memory object once at the start of the level loading (for something that simple it would only take a few ms extra to load, likely unnoticeable)
Do whatever is easier for you to implement and develop for.
Doing it in XML would allow you to design an editor, so that you can use your own GUI to design your content, allowing you to more easily generate much more complex content. It also allows you to modify your content without recompiling your game.
That said, it depends on the scale of your project, and your goals. You should choose the simpler approach if possible, if you want to eventually release it. If you choose the more complex yet more scalable approach, you run the risk of making the project too complex to finish. If your goal is to eventually release, then stay as simple as possible, but if your goal is more along the lines of learning to be a good software engineer, then choosing the more complex approach could be the way to go.