5 ms·

And I'd be happy to get your feedback on how to improve on it.

capableweb 5y ago
It's a bit unclear on why you're using JSON to pass things between main code and the task itself. I can imagine serializing/deserializing that takes quite a bit of CPU time compared to if you just passed native data structures, or at least something binary instead of a format meant for human introspection.
- seinecle 5y ago
  indeed I used Json without giving much thinking to it. Moving to byte arrays improved the performance. Thx!
aww_dang 5y ago
ThreadPool and Queues are my personal preference here
rad_gruchalski 5y ago
It might be worth looking at a generic Callable with your own generic response type, maybe something like Either where Left is an error and Right is your response type. I'd wrap an executor into a provider. Make it accept a WorkItem and the method accepting WorkItem would construct the Callable. I would suggest looking into an optimal way of doing this in, say, Scala and try to replicate some of those learnings in Java. Mind you - I didn't say "write it in Scala". I did say "try in a different language" and take the learnings from there. Scala Future is a good thing to look at.
culturedsystems 5y ago
You didn't want to couple your task to the Runnable interface, so instead you coupled it to an entire HTTP server? And in order to avoid the complexity of calling CompleteableFuture.runAsync, you're using an HTTP client? Could you explain in more detail how you think this is a simplification, because I don't get it? ETA: I'm genuinely baffled by the proposed solution, and I struggled to phrase my comment in a way that didn't come off as confrontational. So please accept my apologies if it still appears overly negative; it's entirely possible I've not understood what your goals and constraints are.
cafxx 5y ago
You may want to look at project loom's virtual threads, that are designed to address almost exactly your problem: https://openjdk.java.net/jeps/8277131 https://openjdk.java.net/jeps/8277131 https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.... https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.html https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.... https://youtu.be/KG24inClY2M https://youtu.be/KG24inClY2M
kjeetgill 5y ago
I think I don't completely understand from the blog your aversion to using standard concurrency tools like Executors.
azth 5y ago
Why not simply: var input = new HashMap<Integer, String>(); var results = new ConcurrentHashMap<Integer, Document>(); var futures = input.entrySet().stream().map(entry -> CompletableFuture.runAsync(() -> { var sentiment = getSentiment(entry.getValue()); results.put(entry.getKey(), new Document(entry.getKey(), sentiment)); }) ); CompletableFuture.allOf(futures.toArray(CompletableFuture[]::new)).join(); Let us know what the speedup is :)

It's a bit unclear on why you're using JSON to pass things between main code and the task itself. I can imagine serializing/deserializing that takes quite a bit of CPU time compared to if you just passed native data structures, or at least something binary instead of a format meant for human introspection.

seinecle 5y ago
indeed I used Json without giving much thinking to it. Moving to byte arrays improved the performance. Thx!

aww_dang 5y ago

ThreadPool and Queues are my personal preference here

rad_gruchalski 5y ago

It might be worth looking at a generic Callable with your own generic response type, maybe something like Either where Left is an error and Right is your response type. I'd wrap an executor into a provider. Make it accept a WorkItem and the method accepting WorkItem would construct the Callable. I would suggest looking into an optimal way of doing this in, say, Scala and try to replicate some of those learnings in Java. Mind you - I didn't say "write it in Scala". I did say "try in a different language" and take the learnings from there. Scala Future is a good thing to look at.

culturedsystems 5y ago

You didn't want to couple your task to the Runnable interface, so instead you coupled it to an entire HTTP server? And in order to avoid the complexity of calling CompleteableFuture.runAsync, you're using an HTTP client? Could you explain in more detail how you think this is a simplification, because I don't get it? ETA: I'm genuinely baffled by the proposed solution, and I struggled to phrase my comment in a way that didn't come off as confrontational. So please accept my apologies if it still appears overly negative; it's entirely possible I've not understood what your goals and constraints are.

cafxx 5y ago

You may want to look at project loom's virtual threads, that are designed to address almost exactly your problem: https://openjdk.java.net/jeps/8277131 https://openjdk.java.net/jeps/8277131 https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.... https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.html https://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part2.... https://youtu.be/KG24inClY2M https://youtu.be/KG24inClY2M

kjeetgill 5y ago

I think I don't completely understand from the blog your aversion to using standard concurrency tools like Executors.

azth 5y ago

Why not simply: var input = new HashMap<Integer, String>(); var results = new ConcurrentHashMap<Integer, Document>(); var futures = input.entrySet().stream().map(entry -> CompletableFuture.runAsync(() -> { var sentiment = getSentiment(entry.getValue()); results.put(entry.getKey(), new Document(entry.getKey(), sentiment)); }) ); CompletableFuture.allOf(futures.toArray(CompletableFuture[]::new)).join(); Let us know what the speedup is :)