[Sugar-devel] Sugar-install-bundle in 13.2.5 is slooow
James Cameron
quozl at laptop.org
Mon Aug 31 20:26:36 EDT 2015
I agree, that might be good.
An strace of sugar-bundle-install shows the huge amount of work
required to start this other instance of the bundle registry, only to
dismantle it on exit.
Alternatively, if there were a method by which sugar-bundle-install
could tell the shell that a new bundle has been installed, there would
be no need to use the bundle registry at all.
This ties in with a recent discussion about how the shell detects
activities installed by a system package manager. Currently an Gio
inotify watch is used, and it suffers from a race condition. It is
overkill compared to a simple notification or signal.
Also, if we trust the Gio inotify watch so much, why are we bothering with
the registry in sugar-bundle-install anyway?
Could we please switch to a SIGHUP handler and a PID file?
diff --git a/bin/sugar-install-bundle b/bin/sugar-install-bundle
index 426c220..b5580bb 100644
--- a/bin/sugar-install-bundle
+++ b/bin/sugar-install-bundle
@@ -4,10 +4,6 @@ import sys
from sugar3.bundle.activitybundle import ActivityBundle
-from dbus.mainloop.glib import DBusGMainLoop
-DBusGMainLoop(set_as_default=True)
-
-
def cmd_help():
print 'Usage: sugar-install-bundle [ bundlename ] \n\n\
Install an activity bundle (.xo). \n'
@@ -16,15 +12,7 @@ if len(sys.argv) != 2:
cmd_help()
sys.exit(2)
-if 'SUGAR_PROFILE' in os.environ:
- # We are in sugar, so use the bundle registry so the correct signals
- # are sent to the activity list
- from jarabe.model.bundleregistry import get_registry
- registry = get_registry()
- bundle = ActivityBundle(sys.argv[1])
- registry.install(bundle, force_downgrade=True)
-else:
- bundle = ActivityBundle(sys.argv[1])
- bundle.install()
+bundle = ActivityBundle(sys.argv[1])
+bundle.install()
print "%s: '%s' installed." % (sys.argv[0], sys.argv[1])
On Mon, Aug 31, 2015 at 03:53:09PM -0300, Gonzalo Odiard wrote:
> Is a good point.
> Maybe we should add a dbus method to register a bundle,
> and a method in the toolkit to do the call,
> then this script use that method.
> I didn't realized this before, because is included in the sugar module,
> but we should not use jarabe here.
>
> Gonzalo
>
> On Mon, Aug 31, 2015 at 2:03 PM, Martin Abente <[1]
> martin.abente.lahaye at gmail.com> wrote:
>
> The problem caused by the race condition is that the activities were not
> refreshed in Sugar activities list when updated or, not added to the list
> when installed. By race condition I mean the situation where the
> BundleRegistry detects changes (e.g. in ~/Activities) too early, when [2]
> activity.info is not available yet, so the bundle gets ignored. I
> personally don't think is related to this issue.
>
> Now, looking at Tony's report and Sam's confirmation that this issue is
> related to the change in [1], my first guess would be that the problem is
> caused by the overhead generated by initializing the BundleRegistry, and
> any other sugar module imported by it, every time the sugar-install-bundle
> script is executed. Note that the script runs in a different process than
> the sugar shell, so the registry instance returned by get_registry() is not
> the same one as the one in the shell. Having SUGAR_PROFILE set doesn't
> necessarily mean the script is being executed in the same context as the
> shell.
>
> If my guess is confirmed, we should revise that change or revert it.
>
> Refs:
> 1. [3]https://github.com/sugarlabs/sugar/commit/
> 64b4b2fba1c37a9ad92ed30eb669b68552b62415
>
> On Mon, Aug 31, 2015 at 9:02 AM, Gonzalo Odiard <[4]godiard at gmail.com>
> wrote:
>
> I am wondering if this issue ca be related to the race condition
> detected
> by Martin when the file monitor detect the activity before the [5]
> activity.info file
> is saved to disk.
>
> Martin, do you have a patch to test?
>
> Gonzalo
>
> On Mon, Aug 31, 2015 at 10:00 AM, Gonzalo Odiard <[6]godiard at gmail.com>
> wrote:
>
> Tony,
> If you can enable logging (remove the comment in the line
> SUGAR_LOGGER_LEVEL
> in the file /home/olpc/.sugar/default/debug)
> And install one of the activities without unset the SUGAR_PROFILE
> env variable,
> and send the log, maybe we can understand better what is happening.
>
> I am afraid the slowness will impact Browse even if you patch it,
> because Browse process
> run in a environment with the env variable set.
>
> One more question: the time is bigger in slower devices (XO-1) than
> in XO-4,
> or is independent of the hardware performance?
>
> Gonzalo
>
> On Sun, Aug 30, 2015 at 7:34 PM, James Cameron <[7]quozl at laptop.org
> > wrote:
>
> G'day Sam,
>
> Adding a flag for a workaround seems like you've given up. ;-)
>
> Wouldn't it be better to fix the problem? As you can see from
> #4849 it occurs in Sugar, and only inside Terminal activity.
>
> Why is it happening?
>
> Why does it take up to 24 minutes to install Browse using
> Terminal?
>
> Why does it take up to 5 minutes to install in Sugar 0.98?
>
> And yet only half a second if the bundle registry is bypassed?
>
> The bundle registry can't be that slow.
>
> By understanding the problem we'll be able to say whether it is
> causing any other slowness of Sugar.
>
> --
> James Cameron
> [8]http://quozl.linux.org.au/
> _______________________________________________
> Sugar-devel mailing list
> [9]Sugar-devel at lists.sugarlabs.org
> [10]http://lists.sugarlabs.org/listinfo/sugar-devel
>
> --
> Gonzalo Odiard
>
>
>
> --
> Gonzalo Odiard
>
>
>
> --
> Gonzalo Odiard
>
> References:
>
> [1] mailto:martin.abente.lahaye at gmail.com
> [2] http://activity.info/
> [3] https://github.com/sugarlabs/sugar/commit/64b4b2fba1c37a9ad92ed30eb669b68552b62415
> [4] mailto:godiard at gmail.com
> [5] http://activity.info/
> [6] mailto:godiard at gmail.com
> [7] mailto:quozl at laptop.org
> [8] http://quozl.linux.org.au/
> [9] mailto:Sugar-devel at lists.sugarlabs.org
> [10] http://lists.sugarlabs.org/listinfo/sugar-devel
--
James Cameron
http://quozl.linux.org.au/
More information about the Sugar-devel
mailing list