| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
didn't seem necessary - its a failure, something is wrong - performance not much better than the original one, its depending on the condition performance actually, which I don't get faster
|
| |
|
|
|
|
| |
its performance considerably.
Channels now use the AsyncQueue, boosting their throughput to about 5k items / s - this is something one can work with, considering the runtime of each item should be large enough to keep the threads busy. This could be a basis, further testing needed
|
| |
|
|
| |
unnecessary tasks to be scheduled as we keep track of how many items will be produced for the task at hand. This introduces additional locking, but performns well in multithreaded mode. Performance of the master queue is still a huge issue, its currently the limiting factor, as bypassing the master queue in serial moode gives 15x performance, wich is what I would need
|
| |
|
|
| |
still inconsistencies that need to be fixed, but it already improved, especially the 4-thread performance which now is as fast as the dual-threaded performance
|
| |
|
|
| |
havok - lets call this a safe-state
|
|
|
including own tests, their design improved to prepare them for some specifics that would be needed for multiprocessing support
|
