Significantly worse performance for PyQt application in Snap vs native Python

snapcraft
1

Code | Snap Store

I have a Python application that uses PyQt as a GUI framework that gets significantly worse performance as a Snap application vs running in Python. As I discussed in this thread it’s a pretty large Snap ~1GB. The app can take very long to open the first time (~15 seconds on my computer) but the performance improves opening subsequent times. Once it has started the Snap application also seems to be less responsive than the native Python version but this isn’t as severe as the start time.

2

does your snap ship all *.pyc files it needs or does it compile on demand (i.e. on first start) ? perhaps pre-compiling them at build time with a clever crafted override-build: snippet could help ?

1 Like
3

Also, you might want to test the new lzo compression option.

3 Likes
4

@argosopentech I believe @ogra is talking about something like this https://github.com/crossbario/crossbar/blob/5aa0682c6ef1edee8ede920873e16571bf4e68a6/snap/snapcraft.yaml#L45, we did that in our code and use that technique in multiple snaps that we publish. It has definitely helped us quite substantially with our snap startup time.

PS: We are working on a PySide2 (Qt for Python) snap as well, its size is 250mb+, however I wouldn’t say the performance is that bad (and I haven’t done the above optimization in that yet).

3 Likes
5

Thanks for the advice, I’ll look into this.

1 Like
6

How did those tweaks work out?

7

Sorry for the late reply.

I tried LZO compression and that seemed to substantially speed up the initial start time so I’m guessing my main issue is decompressing a very large snap on the first start. LZO compression also increased the snap size from ~1GB -> ~1.2GB. This is a relatively small increase in size but I was having issues uploading a snap much larger than my current one to the Snap Store. I don’t think I’m going to switch to LZO compression just yet, and instead try to get the snap size down first, but I think it will make sense eventually.

Since my main issue seems to be fixed with LZO compression I don’t think pre-compiling my *.pyc files with an override-build is worth it for me. I still gave it a try just to see what would happen but wasn’t able to get it to work easily. I tried adding a lightly modified version of @om26er’s linked code:

override-build: |
  snapcraftctl build  
  pip3 install --ignore-installed -U --no-compile --prefix $SNAPCRAFT_PART_INSTALL .
  python3 -m compileall -b $SNAPCRAFT_PART_INSTALL
  find $SNAPCRAFT_PART_INSTALL -type f -name "*.py" -exec rm {} \;
  find $SNAPCRAFT_PART_INSTALL -type f -name "*.so" -exec strip -s {} \;

The above code gave me a permission error for the Python interpreter. I don’t understand Python packaging very well so I’m assuming I’m using @om26er’s code incorrectly and I couldn’t find other examples of people doing this. Since I don’t think I’m going to do *.pyc pre-compilation for now this shouldn’t be an issue for me but putting it here in case anyone’s curious.

8

Finally got to reducing the package size (still not currently live): Optimizing Argos Translate start time