正如我前段时间在this 问题中所述，我在从 Python 访问 sqlite 数据库时遇到了性能问题。为了再次说明这一点，使用apsw 时，相同的代码运行速度提高了 20 倍以上。我最近并行安装了不同版本的 Python，并为此安装了新版本的 apsw。这个版本也跑得很慢。我使用 pythons built-int sqlite3 在另一台计算机上尝试了相同的代码，它运行得很快（但用 apsw 很慢）。我还尝试在我的计算机上安装最新版本的 pysqlite，但运行速度很慢。
我绝对确定这不是架构的问题。
我现在的问题是，我该如何继续诊断错误？
【问题讨论】：
标签： python performance sqlite
万一您可能忽略了这一点，请确保您使用的是the latest versions of both the pysqlite2 data base adapter and the sqlite3 library。链接的答案还显示了如何准确确定您正在使用的每个版本，以及您可能想要添加到问题中的数据。
【讨论】：
我可以在类似的体验上提供我的体验，但使用不同的平台，即 J.
有点慢，我将其定位到sqlite3_get_table 函数。此函数为每一列返回一个指针，每个指针指向一个指针数组，其中每个指针指向一个以空值结尾的字符串。如果函数的结果为空，则指针也可以为空（比如空数据集上的 Max，它将返回空指针，而不是指向空的指针。我讨厌这样。） J 然后将地址形成为可读（形成一个大的地址矩阵，后跟 0 表示偏移量，-1 表示长度，这意味着直到第一个空值）并循环遍历每个地址，最终在其预期的列和行中重新塑造表格。
因此，将数据从 SQLite 提取到另一个平台有一个内存传输方面以及实际读取方面。我发现 J 不容易处理这个通常很大的数据集，这意味着它像所有字符串一样笨重。另外还有那个讨厌的空指针。
我能够将矩阵修改限制到足以优化函数的程度。最后的优化是使用原始代码来读取内存地址 (15!:1)，而不是命名函数 (memr)，因为使用 memr 意味着 J 必须在每个内存中解释 memr 的含义阅读。
总之，如果 python 允许进行一些修改，也许您可以调整数据库访问以更好地满足您的需求。我希望这会有所帮助，但我不抱太大希望...
【讨论】：