| 2019-10-17 19:09:07 |
Jamie Strandboge |
bug |
|
|
added bug |
| 2019-10-17 19:09:07 |
Jamie Strandboge |
attachment added |
|
snap-update-ns.gnome-calculator https://bugs.launchpad.net/bugs/1848567/+attachment/5297969/+files/snap-update-ns.gnome-calculator |
|
| 2019-10-17 19:09:23 |
Jamie Strandboge |
attachment added |
|
snap-update-ns.gnome-calculator.unique https://bugs.launchpad.net/snapd/+bug/1848567/+attachment/5297970/+files/snap-update-ns.gnome-calculator.unique |
|
| 2019-10-17 19:09:56 |
Jamie Strandboge |
description |
I decided to profile the memory usage of apparmor_parser for various snap profiles and discovered that some snaps' auto-generated snap-update-ns profile had thousands of duplicate rules (particularly for snaps using the content interface multiple times). This caused a slowdown of the parser to parse the file as well as excessive memory usage. Eg:
$ for i in /var/lib/snapd/apparmor/profiles/snap*gnome-calculator ; do echo "= $i =" ; /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK $i ; done
= /var/lib/snapd/apparmor/profiles/snap.gnome-calculator.gnome-calculator =
wall: 0:00.43, mem: 22096 Kb
= /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator =
wall: 0:04.88, mem: 1541680 Kb
Whoa, almost 5 seconds to compile on a modern i7 amd64 system and 1.5G used! What is going on?
$ wc -l /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
17547 /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
That's a big profile. :)
Using sort -u on the profile, and then putting the preamble (ie "#include <tunables/global>" and "profile ... {") and the trailing "}" in place so that it is a proper profile, I see:
$ wc -l ./snap-update-ns.gnome-calculator.unique
662 ./snap-update-ns.gnome-calculator.unique
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK ./snap-update-ns.gnome-calculator.unique
wall: 0:00.39, mem: 36276 Kb
That's a *lot* better.
Creating two tasks: there are 2 bugs here: snapd should not be creating a profile with so many duplicate rules and apparmor's deduplication would ideally not use so much memory.
For snapd, I suggest that when auto-generating the snap-update-ns profile, it (efficiently) dedupes before splatting out to the disk. This will cause speedups and lower memory consumption across install and refresh regardless of parser version (not to mention, smaller file sizes).
Attached are the two profiles above generated with snapd 2.42:
$ snap version
snap 2.42
snapd 2.42
series 16
ubuntu 19.04
kernel 5.0.0-29-generic |
I decided to profile the memory usage of apparmor_parser for various snap profiles and discovered that some snaps' auto-generated snap-update-ns profile had thousands of duplicate rules (particularly for snaps using the content interface multiple times). This caused a slowdown of the parser to parse the file as well as excessive memory usage. Eg:
$ for i in /var/lib/snapd/apparmor/profiles/snap*gnome-calculator ; do echo "= $i =" ; /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK $i ; done
= /var/lib/snapd/apparmor/profiles/snap.gnome-calculator.gnome-calculator =
wall: 0:00.43, mem: 22096 Kb
= /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator =
wall: 0:04.88, mem: 1541680 Kb
Whoa, almost 5 seconds to compile on a modern i7 amd64 system and 1.5G of memory used! What is going on?
$ wc -l /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
17547 /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
That's a big profile. :)
Using sort -u on the profile, and then putting the preamble (ie "#include <tunables/global>" and "profile ... {") and the trailing "}" in place so that it is a proper profile, I see:
$ wc -l ./snap-update-ns.gnome-calculator.unique
662 ./snap-update-ns.gnome-calculator.unique
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK ./snap-update-ns.gnome-calculator.unique
wall: 0:00.39, mem: 36276 Kb
That's a *lot* better.
Creating two tasks: there are 2 bugs here: snapd should not be creating a profile with so many duplicate rules and apparmor's deduplication would ideally not use so much memory.
For snapd, I suggest that when auto-generating the snap-update-ns profile, it (efficiently) dedupes before splatting out to the disk. This will cause speedups and lower memory consumption across install and refresh regardless of parser version (not to mention, smaller file sizes).
Attached are the two profiles above generated with snapd 2.42:
$ snap version
snap 2.42
snapd 2.42
series 16
ubuntu 19.04
kernel 5.0.0-29-generic |
|
| 2019-10-17 19:10:06 |
Jamie Strandboge |
bug task added |
|
apparmor |
|
| 2019-10-17 19:10:19 |
Jamie Strandboge |
tags |
|
aa-parser |
|
| 2019-10-17 19:17:29 |
Jamie Strandboge |
description |
I decided to profile the memory usage of apparmor_parser for various snap profiles and discovered that some snaps' auto-generated snap-update-ns profile had thousands of duplicate rules (particularly for snaps using the content interface multiple times). This caused a slowdown of the parser to parse the file as well as excessive memory usage. Eg:
$ for i in /var/lib/snapd/apparmor/profiles/snap*gnome-calculator ; do echo "= $i =" ; /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK $i ; done
= /var/lib/snapd/apparmor/profiles/snap.gnome-calculator.gnome-calculator =
wall: 0:00.43, mem: 22096 Kb
= /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator =
wall: 0:04.88, mem: 1541680 Kb
Whoa, almost 5 seconds to compile on a modern i7 amd64 system and 1.5G of memory used! What is going on?
$ wc -l /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
17547 /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
That's a big profile. :)
Using sort -u on the profile, and then putting the preamble (ie "#include <tunables/global>" and "profile ... {") and the trailing "}" in place so that it is a proper profile, I see:
$ wc -l ./snap-update-ns.gnome-calculator.unique
662 ./snap-update-ns.gnome-calculator.unique
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK ./snap-update-ns.gnome-calculator.unique
wall: 0:00.39, mem: 36276 Kb
That's a *lot* better.
Creating two tasks: there are 2 bugs here: snapd should not be creating a profile with so many duplicate rules and apparmor's deduplication would ideally not use so much memory.
For snapd, I suggest that when auto-generating the snap-update-ns profile, it (efficiently) dedupes before splatting out to the disk. This will cause speedups and lower memory consumption across install and refresh regardless of parser version (not to mention, smaller file sizes).
Attached are the two profiles above generated with snapd 2.42:
$ snap version
snap 2.42
snapd 2.42
series 16
ubuntu 19.04
kernel 5.0.0-29-generic |
I decided to profile the memory usage of apparmor_parser for various snap profiles and discovered that some snaps' auto-generated snap-update-ns profile had thousands of duplicate rules (particularly for snaps using the content interface multiple times). This caused a slowdown of the parser to parse the file as well as excessive memory usage. Eg:
$ for i in /var/lib/snapd/apparmor/profiles/snap*gnome-calculator ; do echo "= $i =" ; /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK $i ; done
= /var/lib/snapd/apparmor/profiles/snap.gnome-calculator.gnome-calculator =
wall: 0:00.43, mem: 22096 Kb
= /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator =
wall: 0:04.88, mem: 1541680 Kb
Whoa, almost 5 seconds to compile on a modern i7 amd64 system and 1.5G of memory used! What is going on?
$ wc -l /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
17547 /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
That's a big profile. :)
Using sort -u on the profile, and then putting the preamble (ie "#include <tunables/global>" and "profile ... {") and the trailing "}" in place so that it is a proper profile, I see:
$ wc -l ./snap-update-ns.gnome-calculator.unique
662 ./snap-update-ns.gnome-calculator.unique
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK ./snap-update-ns.gnome-calculator.unique
wall: 0:00.39, mem: 36276 Kb
That's a *lot* better. Note, while my machine has 4 CPUs, using -j1 doesn't make a difference:
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -j1 -QTK /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
wall: 0:05.32, mem: 1541236 Kb
Creating two tasks: there are 2 bugs here: snapd should not be creating a profile with so many duplicate rules and apparmor's deduplication would ideally not use so much memory.
For snapd, I suggest that when auto-generating the snap-update-ns profile, it (efficiently) dedupes before splatting out to the disk. This will cause speedups and lower memory consumption across install and refresh regardless of parser version (not to mention, smaller file sizes).
Attached are the two profiles above generated with snapd 2.42:
$ snap version
snap 2.42
snapd 2.42
series 16
ubuntu 19.04
kernel 5.0.0-29-generic |
|
| 2019-10-17 19:22:13 |
Jamie Strandboge |
description |
I decided to profile the memory usage of apparmor_parser for various snap profiles and discovered that some snaps' auto-generated snap-update-ns profile had thousands of duplicate rules (particularly for snaps using the content interface multiple times). This caused a slowdown of the parser to parse the file as well as excessive memory usage. Eg:
$ for i in /var/lib/snapd/apparmor/profiles/snap*gnome-calculator ; do echo "= $i =" ; /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK $i ; done
= /var/lib/snapd/apparmor/profiles/snap.gnome-calculator.gnome-calculator =
wall: 0:00.43, mem: 22096 Kb
= /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator =
wall: 0:04.88, mem: 1541680 Kb
Whoa, almost 5 seconds to compile on a modern i7 amd64 system and 1.5G of memory used! What is going on?
$ wc -l /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
17547 /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
That's a big profile. :)
Using sort -u on the profile, and then putting the preamble (ie "#include <tunables/global>" and "profile ... {") and the trailing "}" in place so that it is a proper profile, I see:
$ wc -l ./snap-update-ns.gnome-calculator.unique
662 ./snap-update-ns.gnome-calculator.unique
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK ./snap-update-ns.gnome-calculator.unique
wall: 0:00.39, mem: 36276 Kb
That's a *lot* better. Note, while my machine has 4 CPUs, using -j1 doesn't make a difference:
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -j1 -QTK /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
wall: 0:05.32, mem: 1541236 Kb
Creating two tasks: there are 2 bugs here: snapd should not be creating a profile with so many duplicate rules and apparmor's deduplication would ideally not use so much memory.
For snapd, I suggest that when auto-generating the snap-update-ns profile, it (efficiently) dedupes before splatting out to the disk. This will cause speedups and lower memory consumption across install and refresh regardless of parser version (not to mention, smaller file sizes).
Attached are the two profiles above generated with snapd 2.42:
$ snap version
snap 2.42
snapd 2.42
series 16
ubuntu 19.04
kernel 5.0.0-29-generic |
I decided to profile the memory usage of apparmor_parser for various snap profiles and discovered that some snaps' auto-generated snap-update-ns profile had thousands of duplicate rules (particularly for snaps using the content interface multiple times). This caused a slowdown of the parser to parse the file as well as excessive memory usage. Eg:
$ for i in /var/lib/snapd/apparmor/profiles/snap*gnome-calculator ; do echo "= $i =" ; /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK $i ; done
= /var/lib/snapd/apparmor/profiles/snap.gnome-calculator.gnome-calculator =
wall: 0:00.43, mem: 22096 Kb
= /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator =
wall: 0:04.88, mem: 1541680 Kb
Whoa, almost 5 seconds to compile on a modern i7 amd64 system and 1.5G of memory used.
$ wc -l /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
17547 /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
That's a big profile. :)
Using sort -u on the profile, and then putting the preamble (ie "#include <tunables/global>" and "profile ... {") and the trailing "}" in place so that it is a proper profile, I see:
$ wc -l ./snap-update-ns.gnome-calculator.unique
662 ./snap-update-ns.gnome-calculator.unique
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK ./snap-update-ns.gnome-calculator.unique
wall: 0:00.39, mem: 36276 Kb
That's a *lot* better. Note, while my machine has 4 CPUs, using -j1 doesn't make a difference:
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -j1 -QTK /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
wall: 0:05.32, mem: 1541236 Kb
Creating two tasks: there are 2 bugs here: snapd should not be creating a profile with so many duplicate rules and apparmor's deduplication would ideally not use so much memory.
For snapd, I suggest that when auto-generating the snap-update-ns profile, it (efficiently) dedupes before splatting out to the disk. This will cause speedups and lower memory consumption across install and refresh regardless of parser version (not to mention, smaller file sizes).
Attached are the two profiles above generated with snapd 2.42:
$ snap version
snap 2.42
snapd 2.42
series 16
ubuntu 19.04
kernel 5.0.0-29-generic |
|
| 2019-10-17 19:22:59 |
Jamie Strandboge |
description |
I decided to profile the memory usage of apparmor_parser for various snap profiles and discovered that some snaps' auto-generated snap-update-ns profile had thousands of duplicate rules (particularly for snaps using the content interface multiple times). This caused a slowdown of the parser to parse the file as well as excessive memory usage. Eg:
$ for i in /var/lib/snapd/apparmor/profiles/snap*gnome-calculator ; do echo "= $i =" ; /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK $i ; done
= /var/lib/snapd/apparmor/profiles/snap.gnome-calculator.gnome-calculator =
wall: 0:00.43, mem: 22096 Kb
= /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator =
wall: 0:04.88, mem: 1541680 Kb
Whoa, almost 5 seconds to compile on a modern i7 amd64 system and 1.5G of memory used.
$ wc -l /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
17547 /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
That's a big profile. :)
Using sort -u on the profile, and then putting the preamble (ie "#include <tunables/global>" and "profile ... {") and the trailing "}" in place so that it is a proper profile, I see:
$ wc -l ./snap-update-ns.gnome-calculator.unique
662 ./snap-update-ns.gnome-calculator.unique
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK ./snap-update-ns.gnome-calculator.unique
wall: 0:00.39, mem: 36276 Kb
That's a *lot* better. Note, while my machine has 4 CPUs, using -j1 doesn't make a difference:
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -j1 -QTK /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
wall: 0:05.32, mem: 1541236 Kb
Creating two tasks: there are 2 bugs here: snapd should not be creating a profile with so many duplicate rules and apparmor's deduplication would ideally not use so much memory.
For snapd, I suggest that when auto-generating the snap-update-ns profile, it (efficiently) dedupes before splatting out to the disk. This will cause speedups and lower memory consumption across install and refresh regardless of parser version (not to mention, smaller file sizes).
Attached are the two profiles above generated with snapd 2.42:
$ snap version
snap 2.42
snapd 2.42
series 16
ubuntu 19.04
kernel 5.0.0-29-generic |
I decided to profile the memory usage of apparmor_parser for various snap profiles and discovered that some snaps' auto-generated snap-update-ns profile had thousands of duplicate rules (particularly for snaps using the content interface multiple times). This caused a slowdown of the parser to parse the file as well as excessive memory usage. Eg:
$ for i in /var/lib/snapd/apparmor/profiles/snap*gnome-calculator ; do echo "= $i =" ; /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK $i ; done
= /var/lib/snapd/apparmor/profiles/snap.gnome-calculator.gnome-calculator =
wall: 0:00.43, mem: 22096 Kb
= /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator =
wall: 0:04.88, mem: 1541680 Kb
Whoa, almost 5 seconds to compile on a modern i7 amd64 system and 1.5G of memory used.
$ wc -l /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
17547 /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
That's a big profile. :)
Using sort -u on the profile, and then putting the preamble (ie "#include <tunables/global>" and "profile ... {") and the trailing "}" in place so that it is a proper profile, I see:
$ wc -l ./snap-update-ns.gnome-calculator.unique
662 ./snap-update-ns.gnome-calculator.unique
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK ./snap-update-ns.gnome-calculator.unique
wall: 0:00.39, mem: 36276 Kb
That's a *lot* better. Note, while my machine has 4 CPUs, using -j1 doesn't make a difference:
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -j1 -QTK /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
wall: 0:05.32, mem: 1541236 Kb
Creating two tasks since there are 2 bugs here: snapd should not be creating a profile with so many duplicate rules and apparmor's deduplication would ideally not use so much memory.
For snapd, I suggest that when auto-generating the snap-update-ns profile, it (efficiently) dedupes before splatting out to the disk. This will cause speedups and lower memory consumption across install and refresh regardless of parser version (not to mention, smaller file sizes).
Attached are the two profiles above generated with snapd 2.42:
$ snap version
snap 2.42
snapd 2.42
series 16
ubuntu 19.04
kernel 5.0.0-29-generic |
|
| 2019-10-17 20:05:55 |
Jamie Strandboge |
summary |
autogenerated per-snap snap-update-ns apparmor profile may contain many duplicate rules causing excessive parser memory usage |
autogenerated per-snap snap-update-ns apparmor profile may contain many duplicate mount rules causing excessive parser memory usage |
|
| 2019-10-18 13:31:57 |
Jamie Strandboge |
description |
I decided to profile the memory usage of apparmor_parser for various snap profiles and discovered that some snaps' auto-generated snap-update-ns profile had thousands of duplicate rules (particularly for snaps using the content interface multiple times). This caused a slowdown of the parser to parse the file as well as excessive memory usage. Eg:
$ for i in /var/lib/snapd/apparmor/profiles/snap*gnome-calculator ; do echo "= $i =" ; /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK $i ; done
= /var/lib/snapd/apparmor/profiles/snap.gnome-calculator.gnome-calculator =
wall: 0:00.43, mem: 22096 Kb
= /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator =
wall: 0:04.88, mem: 1541680 Kb
Whoa, almost 5 seconds to compile on a modern i7 amd64 system and 1.5G of memory used.
$ wc -l /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
17547 /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
That's a big profile. :)
Using sort -u on the profile, and then putting the preamble (ie "#include <tunables/global>" and "profile ... {") and the trailing "}" in place so that it is a proper profile, I see:
$ wc -l ./snap-update-ns.gnome-calculator.unique
662 ./snap-update-ns.gnome-calculator.unique
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK ./snap-update-ns.gnome-calculator.unique
wall: 0:00.39, mem: 36276 Kb
That's a *lot* better. Note, while my machine has 4 CPUs, using -j1 doesn't make a difference:
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -j1 -QTK /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
wall: 0:05.32, mem: 1541236 Kb
Creating two tasks since there are 2 bugs here: snapd should not be creating a profile with so many duplicate rules and apparmor's deduplication would ideally not use so much memory.
For snapd, I suggest that when auto-generating the snap-update-ns profile, it (efficiently) dedupes before splatting out to the disk. This will cause speedups and lower memory consumption across install and refresh regardless of parser version (not to mention, smaller file sizes).
Attached are the two profiles above generated with snapd 2.42:
$ snap version
snap 2.42
snapd 2.42
series 16
ubuntu 19.04
kernel 5.0.0-29-generic |
I decided to profile the memory usage of apparmor_parser for various snap profiles and discovered that some snaps' auto-generated snap-update-ns profile had thousands of duplicate rules (particularly for snaps using the content interface multiple times). This caused a slowdown of the parser to parse the file as well as excessive memory usage. Eg:
$ for i in /var/lib/snapd/apparmor/profiles/snap*gnome-calculator ; do echo "= $i =" ; /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK -Ono-expr-simplify $i ; done
= /var/lib/snapd/apparmor/profiles/snap.gnome-calculator.gnome-calculator =
wall: 0:00.43, mem: 22096 Kb
= /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator =
wall: 0:04.88, mem: 1541680 Kb
Whoa, almost 5 seconds to compile on a modern i7 amd64 system and 1.5G of memory used.
$ wc -l /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
17547 /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
That's a big profile. :)
Using sort -u on the profile, and then putting the preamble (ie "#include <tunables/global>" and "profile ... {") and the trailing "}" in place so that it is a proper profile, I see:
$ wc -l ./snap-update-ns.gnome-calculator.unique
662 ./snap-update-ns.gnome-calculator.unique
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -QTK -Ono-expr-simplify ./snap-update-ns.gnome-calculator.unique
wall: 0:00.39, mem: 36276 Kb
That's a *lot* better. Note, while my machine has 4 CPUs, using -j1 doesn't make a difference:
$ /usr/bin/time -f "wall: %E, mem: %M Kb" apparmor_parser -j1 -QTK -Ono-expr-simplify /var/lib/snapd/apparmor/profiles/snap-update-ns.gnome-calculator
wall: 0:05.32, mem: 1541236 Kb
Creating two tasks since there are 2 bugs here: snapd should not be creating a profile with so many duplicate rules and apparmor's deduplication would ideally not use so much memory.
For snapd, I suggest that when auto-generating the snap-update-ns profile, it (efficiently) dedupes before splatting out to the disk. This will cause speedups and lower memory consumption across install and refresh regardless of parser version (not to mention, smaller file sizes).
Attached are the two profiles above generated with snapd 2.42:
$ snap version
snap 2.42
snapd 2.42
series 16
ubuntu 19.04
kernel 5.0.0-29-generic |
|
| 2019-10-18 14:09:45 |
Zygmunt Krynicki |
snapd: status |
New |
In Progress |
|
| 2019-10-18 14:09:47 |
Zygmunt Krynicki |
snapd: assignee |
|
Zygmunt Krynicki (zyga) |
|
| 2019-10-18 16:34:46 |
Zygmunt Krynicki |
snapd: importance |
Undecided |
Medium |
|
| 2019-10-20 08:57:36 |
Plurtu |
bug |
|
|
added subscriber Plurtu |
| 2019-10-23 23:16:26 |
Traumflug |
bug |
|
|
added subscriber Traumflug |
| 2019-10-24 11:37:49 |
Zygmunt Krynicki |
snapd: milestone |
|
2.43 |
|
| 2019-10-25 08:49:15 |
Zygmunt Krynicki |
snapd: status |
In Progress |
Fix Committed |
|
| 2019-11-07 15:15:04 |
Zygmunt Krynicki |
snapd: milestone |
2.43 |
2.42.1 |
|
| 2019-11-07 15:15:26 |
Zygmunt Krynicki |
snapd: status |
Fix Committed |
Fix Released |
|
