Hiệu suất của mutlithead trong RX vs Thead vs Executors

Tôi đang viết một ứng dụng phụ trợ trong Kotlin.

Để tăng tốc mọi thứ, tôi hiện đang dựa vào RxKotlin trên máy chủ để thực hiện song song các tác vụ IO như cuộc gọi cơ sở dữ liệu & lệnh gọi API. Mã thường trông như thế này.

val singleResult1 = Single.fromCallable{
  database.get(....)
}.io()

val singleResult2 = Single.fromCallable{
  database.update(....)
}.io()

Single.zip(singleResult1, singleResult2){ result1: Result1, result2: Result2 ->
    ....
}
.flatMap{
  //other RX calls
}
.subscribeOn(Schedulers.io())
.observeOn(Schedulers.computation())
.blockingGet()

Tuy nhiên, vì không hoạt động thực sự hoạt động với nhiều sự kiện (chỉ là đơn), Rx cảm thấy hơi lộn xộn và chỉ thêm một bó nồi hơi (nó cũng gây ra sự phức tạp nếu tôi muốn trả về giá trị null và đôi khi có thể làm hỏng dấu vết ngăn xếp )

Tôi đang nghĩ đến việc loại bỏ Rx và sử dụng Executors(hoặc chủ đề) cho song song thay thế. Có bất kỳ cân nhắc hiệu suất để xem xét ở đây?

Ví dụ những gì tôi nghĩ về:

fun <T> waitAll(tasks: List<Callable<T>>, threadCount: Int = -1): List<T> {
    val threads = if (threadCount == -1) tasks.size else threadCount
    val executor = Executors.newFixedThreadPool(threads)
    val results = executor.invokeAll(tasks).map {
        it.get()
    }
    executor.shutdown()
    return results
}

Và sử dụng nó như vậy:

waitAll(listOf(callable1, callable2))

Hoặc có thể sử dụng chủ đề thường xuyên và tham gia chúng?

threads.forEach{
   it.start()
}
threads.forEach{
   it.join()
}

Hay tại sao không stream?

listOf(callable1,callable2)
.parallelStream()
.map{it.call()}
.collect(Collectors.toList())

Bản thân KotlinRx sử dụng các trình thực thi, ngoại trừ nó có hai nhóm luồng được tạo trước bên dưới Schedulers.io()(không giới hạn) và Schedulers.computation()(giới hạn bởi số lượng lõi) và không quay lên một luồng mới mỗi lần như mã được đề xuất của bạn. Mà rõ ràng bạn cũng có thể làm thủ công:

private val executor = Executors.newCachedThreadPool() // equivalent to io()

fun <T> waitAll(tasks: List<Callable<T>>): List<T> {
    return executor.invokeAll(tasks).map {
        it.get()
    }
}

Đây nên là tốt hơn so với việc tạo ra một chủ đề cho mỗi công việc, nói chung, bằng cách cho phép sử dụng lại chủ đề hiện có, nhưng phụ thuộc vào cách sử dụng của bạn.

coroutines là (IMO) phù hợp hơn để xử lý giao tiếp nền / ui-thread (tức là Android, v.v.)

Việc coroutines có hữu ích cho việc này hay không phụ thuộc rất nhiều vào những gì bạn có trong nhiệm vụ của mình. API chặn (ví dụ: JDBC)? Họ không. Một async one (ví dụ Retrofit)? Họ đang.

Các dịch vụ Java Executor sử dụng Chủ đề và RxKotlin sử dụng ExecutorService. Vì vậy, tất cả những điều này là giống nhau trong nền. Sự khác biệt là kiến ​​trúc phần mềm. Vì vậy, nếu bạn chọn kiến ​​trúc tốt nhất được tích hợp với mã của mình, nó sẽ hoạt động tốt nhất và thực hiện công việc một cách chính xác. Đơn giản là điều tốt nhất.

Nếu bạn có một kiến ​​trúc dựa trên sự kiện hoặc có thể quan sát được và bạn đang cố gắng triển khai một thư viện mới để làm việc với các hoạt động hoặc công việc dựa trên sự kiện, bạn có thể viết các bước sai về phân tách công việc hoặc thời gian. Sử dụng RxKotlin và không phát minh lại bánh xe.

Nếu công việc của bạn không liên quan đến các sự kiện hoặc mô hình có thể quan sát được và bạn chỉ cần thực hiện các công việc song song, chỉ cần sử dụng các dịch vụ Executor. RxKotlin sẽ vượt qua kỹ thuật. Khi bạn sử dụng RxKotlin trong tình huống này, bạn cần phải làm nhiều thứ hơn thì bạn cần.

Vì vậy, tôi nghĩ rằng câu hỏi không phải là tốc độ trong tình huống này, kiến ​​trúc là.