General, Gmail: BatchRequest for 25 gmail threads is very slow

[gshahbazian]

Environment details

2. OS type and version: Android 30
3. Java version: 8, kotlin 1.4.0
4. google-api-client version(s): 1.30.10

Steps to reproduce

Use the BatchRequest class to fetch 25 threads from Gmail

Code example

val gmailService: Gmail // Configured Gmail service
val batch = gmailService.batch()

// List of 25 thread ids
val threadIds = listOf("THREAD_ID" ...)

for (threadId in threadIds) {
  batch.queue<Thread, GoogleJsonErrorContainer>(
    gmailService.users().Threads().get("me", threadId).buildHttpRequest(),
    Thread::class.java,
    GoogleJsonErrorContainer::class.java,
    object : BatchCallback<Thread, GoogleJsonErrorContainer> {
        override fun onSuccess(t: Thread, responseHeaders: HttpHeaders?) {
            println("BATCH SUCCESS")
        }
        override fun onFailure(e: GoogleJsonErrorContainer, responseHeaders: HttpHeaders?) {
            println("BATCH ERROR: ${e.error?.message}")
        }
    }
  )
}

batch.execute()

Stack trace

Pausing the debugger while batches are being returned pauses here:

google-api-java-client/google-api-client/src/main/java/com/google/api/client/googleapis/batch/BatchUnparsedResponse.java

Line 127 in ce22c0e

while ((line = readRawLine()) != null && !line.startsWith(boundary)) {

The entire batch takes ~2 minutes to return while the google-api-objectivec-client-for-rest library returns the same set in < 2 seconds.

[gshahbazian]

I've tracked this down further. The degraded performance occurs when the response is gzipped and the request getContent() returns a GZIPInputStream. Accessing this stream type byte by byte to separate each batched response is extremely slow.

Locally I've added a workaround which reads the entire stream upfront and passes a simple ByteArrayInputStream to BatchUnparsedResponse. Workaround code change: superhuman#1

[chingor13]

It looks like we originally did not use a BufferedReader because it does not handle all of HTTP RFC 2616. We also don't want to read the entire response upfront as that could blow our memory usage given a huge response.

We will likely want to add buffering to the current implementation to reduce the number of direct reads from the GZipInputStream while limiting memory usage.