Multiple threads in single class or multiple threads in multiple classes --which is efficient?
posted 6 years ago
Its all about coherence. If you want multiple classes to do your job, running multiple threads for it, make sure that each and every class is coherent enough otherwise you've minimized reuse.
From performance point of view :
single object multiple threads is faster than multiple objects with multiple threads and moreover former occupies less space. But it doesn't mean you always chose the former unless the class is coherent.
From performance point of view :
single object multiple threads is faster than multiple objects with multiple threads and moreover former occupies less space. But it doesn't mean you always chose the former unless the class is coherent.
posted 6 years ago
This question is extremely vague.
It's like asking "There's a blue car with 12 inch wheels and a red car with 15 inch wheels. Which color car is more efficient?" What's your answer to that?
The answer is that it's impossible to say without details. The real problem is that the question itself needs rewording and rethinking. There is no single correct answer to that question. Just as you need more data about the cars - power, weight, terrain, drive characteristics, road surface, fuel consumption and so on - to even make a prediction, you need more details about your problem. And even then, there are likely to be multiple answers for different combinations of these factors.
Coming to your question, number of classes has little bearing on performance and resource consumption at runtime. Those really depend on
- your application algorithms, logic, and how they consume resources like CPU, memory and storage
- how your instances collaborate
- thread synchronization strategies
- state of the hardware and software environment in which the JVM is running
Start with a simple logic on paper that would work correctly to the best of your knowledge and fulfills all functional requirements.
See if your logic is making some obvious mistakes (example: multiple fetches across network can be optimized by fetching in bulk, or caching locally).
Think of solutions to such obvious bottlenecks, and incrementally refine your logic to overcome them.
Then implement that logic.
Measure performance using profilers.
If - and only if - it does not meet some of your target numbers, find where are the bottlenecks, question your assumptions made earlier, and redesign / refactor /tune as needed. using common design principles (for example, sometimes logic can be made faster by avoiding synchronization, but that may require using separate data structures per thread and not sharing any data structure - which means more memory will be consumed. So you need to be comfortable with such tradeoffs).
Measure again, find bottlenecks and repeat the process, till all your performance numbers are met.
archana gangaiah wrote: Please let me know which of the above option is more efficient way
This question is extremely vague.
It's like asking "There's a blue car with 12 inch wheels and a red car with 15 inch wheels. Which color car is more efficient?" What's your answer to that?
The answer is that it's impossible to say without details. The real problem is that the question itself needs rewording and rethinking. There is no single correct answer to that question. Just as you need more data about the cars - power, weight, terrain, drive characteristics, road surface, fuel consumption and so on - to even make a prediction, you need more details about your problem. And even then, there are likely to be multiple answers for different combinations of these factors.
Coming to your question, number of classes has little bearing on performance and resource consumption at runtime. Those really depend on
- your application algorithms, logic, and how they consume resources like CPU, memory and storage
- how your instances collaborate
- thread synchronization strategies
- state of the hardware and software environment in which the JVM is running
Start with a simple logic on paper that would work correctly to the best of your knowledge and fulfills all functional requirements.
See if your logic is making some obvious mistakes (example: multiple fetches across network can be optimized by fetching in bulk, or caching locally).
Think of solutions to such obvious bottlenecks, and incrementally refine your logic to overcome them.
Then implement that logic.
Measure performance using profilers.
If - and only if - it does not meet some of your target numbers, find where are the bottlenecks, question your assumptions made earlier, and redesign / refactor /tune as needed. using common design principles (for example, sometimes logic can be made faster by avoiding synchronization, but that may require using separate data structures per thread and not sharing any data structure - which means more memory will be consumed. So you need to be comfortable with such tradeoffs).
Measure again, find bottlenecks and repeat the process, till all your performance numbers are met.
