Anki from Winows installer is significantly slower than running 'aqt' from pypi

Anki Desktop
1

Just an observation: when I run Anki 2.1.49 via my local Windows Python 3.9.0 installation it is significantly faster than via the official installer.

For example in the browser, viewing the root deck (177k cards) takes nearly 1 second on the official build, and maybe 200 milliseconds on the local Python.

2

That’s curious. When running from a local Python version you’re likely using Qt5.15 instead of .14, so that’s one possible explanation. If you use the debug console to benchmark a backend call like mw.col.find_cards("") to rule out the GUI, are the second run times of each version similar? Does adding an exception to your antivirus program help?

3

I turned off my antivirus and it didn’t seem to make a difference. There’s a pretty big difference on the query time between the two builds:

Installed Anki 2.1.49:

import time
… start = time.time()
… print(len(mw.col.find_cards(“”)))
… end = time.time()
… print(end - start)
177476
0.4509773254394531

PyPI Anki 2.1.49:

import time
… start = time.time()
… print(len(mw.col.find_cards(“”)))
… end = time.time()
… print(end - start)
177476
0.015376091003417969

4

That’s fascinating. I feared something might have gone wrong with the build process causing you to end up with a debug build, but no, the rsbridge.pyd file where the searching logic lies is identical in the wheel and the binary build, as it should be. What performance do you see with 2.1.50beta2?

https://betas.ankiweb.net/

5

anki-2.1.50+beta2_db804d95-windows-qt5.exe

import time
… start = time.time()
… print(len(mw.col.find_cards(“”)))
… end = time.time()
… print(end - start)
177476
0.013901948928833008

rsbridge.pyd in the 2.1.49 build is identical on my setup too.

6

Could it just by the Python interpreter difference?

7

I guess it’s possible, but it’s a pretty stark difference. One other possibility is something related to pyinstaller, which 2.1.50 is not using.

8

It appears to be an issue with Qt 5.14 - installing that version in a venv triggers the same performance regression as the packaged build. 2.1.50 was forced to update to 5.15 on Windows anyway as there’s no package of 5.14 on Python 3.9, so this shouldn’t be an issue moving forward.