From 63b33d4181d3e1111b33fdf3d01cb40d768b8e27 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 18 Nov 2022 16:23:20 -0400 Subject: [PATCH] update --- .../comment_15_145e29b42c46f15efc21c6d1ef9dd82d._comment | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/doc/bugs/performance_regression__63___init_takes_times_more/comment_15_145e29b42c46f15efc21c6d1ef9dd82d._comment b/doc/bugs/performance_regression__63___init_takes_times_more/comment_15_145e29b42c46f15efc21c6d1ef9dd82d._comment index 8348daadf0..379aafa328 100644 --- a/doc/bugs/performance_regression__63___init_takes_times_more/comment_15_145e29b42c46f15efc21c6d1ef9dd82d._comment +++ b/doc/bugs/performance_regression__63___init_takes_times_more/comment_15_145e29b42c46f15efc21c6d1ef9dd82d._comment @@ -13,11 +13,8 @@ something else. Weird! However, I also dumped the database to a sql script. Running that script with sqlite3 takes only 2.39 seconds. So, persistent-sqlite does have some -performance overhead. My suspicion from profiling is that it's due to -conversion between data types. First it builts up a Text containing a SQL -statement (and not using a Builder). Then it uses encodeUtf8 on it to get -a ByteString, and then it uses useAsCString. So there are 2 or 3 copies -of the input data, which takes time and increases the allocations. +performance overhead. Opened an issue: + The test program: