Sqldelight: [Native] More time is spent in stripping string margins than actually executing the DML queries

[andersio]

Runtime Environment
SQLDelight version: 1.4.4
Application OS: iOS 14.0

Describe the bug

A simple UPSERT query:

upsert:
INSERT INTO Entity VALUES ?
ON CONFLICT (id, parentId) DO
UPDATE SET name = excluded.name, imageFilename = excluded.imageFilename, color = excluded.color;

Profiling with Xcode Instruments shows that, even with all compiler optimizations enabled (-opt), the generated code spends more time in stripping margins than executing the query.

An example run:

• 600.60 ms kfun:mypackage.EntityQueriesImpl.upsert
  
  
  
  • 304.80 ms kfun:kotlin.text#[email protected](kotlin.String?;kotlin.Int){}kotlin.String
  
  
  • 279.00 ms (inlined) NativeSqlDriver#execute()
    
    
    
    
    
    • 278.10 ms ConnectionWrapper#execute()
      
      
      
      
      
      
      
      • ...
        
        
        
        
        
        
        
        
        
        • 76.00 ms NativeStatement#execute()
        
        
        
        
        
      
      
      
      
    
    
    
  
  

It's gonna take a very large dataset with lots of indexes to beat the time spent in trimming margins alone, notwithstanding the low hanging fruit in the native driver yet to be picked.

~While it could be K/N implementation of trimMargins() being underwhelming,~^[1] Do we really have to trim the margins from the generated SQL text at runtime? The SQLite compiler should deal with these varying amount of whitespaces alright, shouldn't it?

_^[1] Turns out it is common code._

[andersio]

Looks like there is optimization for trimMargin() in JVM. So this affects only native.

Even though IMO this should be addressed in the compiler, having SQLDelight to stop applying trimMargin() seems an acceptable temporary workaround. This is especially relevant when doing large batches of DML statements, whose SQL text is repeatedly stripped for every single call.

JVM issue: https://youtrack.jetbrains.com/issue/KT-17755
(Newly filed) Native issue: https://youtrack.jetbrains.com/issue/KT-44421

[JakeWharton]

I'm pretty sure I landed the optimization for IR which should include native. But this was like... two years ago, so my memory is fuzzy.

I'm opposed to any action on our side. Let's fix the Kotlin compiler.

[JakeWharton]

Hmm maybe I never followed up. IR PR is here: https://github.com/JetBrains/kotlin/pull/2290

[JakeWharton]

This landed in native at https://github.com/JetBrains/kotlin-native/pull/4647. Will likely be in 1.5.0 unless there's going to be a 1.4.40.

[AlecStrong]

gonna close this out since it'll happen with a kotlin upgrade eventually