[Bug 1282311] Re: [FFe] libclick
Colin Watson
cjwatson at canonical.com
Sat Mar 1 23:52:51 UTC 2014
** Description changed:
I initially wrote click in Python in order to be able to get it up and
running quickly. I still think Python is appropriate for large chunks
of it, particularly the parts that are only run by developers ("click
build", "click chroot", etc.), but it is not ideal to have to go through
Python in resource-constrained environments such as phones. When we
start up Ubuntu Touch in an ARM emulator, it takes a very long time to
run all the click hooks, which directly affects how quickly we can turn
round CI tests; and I've also heard that various queries from desktop
infrastructure currently made by way of running click as a subprocess
can contribute as much as a second to application startup time. This is
obviously unacceptable and we need to do something about it.
Not wanting to do a scorched-earth rewrite, my approach to this is to
- rewrite hot parts of click in C and expose them as a "libclick" library,
- using GObject in order to gain introspection support and thus trivially
- have Python bindings available. This will allow me to translate things
- gradually, and in particular it will let me leave the existing rather
- comprehensive test suite in place with only minimal adjustments, which
- will provide quite good assurance that I haven't broken anything too
- seriously. By itself, it may well not speed things up very much as the
- top-level /usr/bin/click program will still be a Python script (at least
- for the moment), but we will be able to gain significant improvements to
- application startup time shortly afterwards with a few very small
- changes to packages such as upstart-app-launch.
+ rewrite hot parts of click in Vala (previously C, but I found that I was
+ writing too much error handling boilerplate by hand and Vala has the
+ right layer of abstraction here) and expose them as a "libclick"
+ library, using GObject in order to gain introspection support and thus
+ trivially have Python bindings available. This will allow me to
+ translate things gradually, and in particular it will let me leave the
+ existing rather comprehensive test suite in place with only minimal
+ adjustments, which will provide quite good assurance that I haven't
+ broken anything too seriously. By itself, it may well not speed things
+ up very much as the top-level /usr/bin/click program will still be a
+ Python script (at least for the moment), but we will be able to gain
+ significant improvements to application startup time shortly afterwards
+ with a few very small changes to packages such as upstart-app-launch.
I had hoped to have an initial version of this in place well before
feature freeze, and have been coding frenetically over the last week to
try to achieve that. Unfortunately, the basic query functionality
that's top of the list for libclick requires essentially the whole
interwoven edifice of click.{database,hooks,user}, which is around 1000
- lines of Python code, and I'm somewhere north of 3000 lines of
- corresponding C code now without being finished yet. If I were able to
- separate out any particularly useful subset of this, I would, but I
- don't think it's realistic. I also don't want to try to rush a landing
- given how critical it is to the phone.
+ lines of Python code, turning into around 2500 lines of Vala (it would
+ have been more like 5000 lines of C). If I were able to separate out
+ any particularly useful subset of this, I would, but I don't think it's
+ realistic. I also don't want to try to rush a landing given how
+ critical it is to the phone.
As such, I'd like to apply for a feature freeze exception for the work
described here. Based on my current rate of progress, I expect to have
something worth landing by around the end of next week.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1282311
Title:
[FFe] libclick
Status in “click” package in Ubuntu:
New
Bug description:
I initially wrote click in Python in order to be able to get it up and
running quickly. I still think Python is appropriate for large chunks
of it, particularly the parts that are only run by developers ("click
build", "click chroot", etc.), but it is not ideal to have to go
through Python in resource-constrained environments such as phones.
When we start up Ubuntu Touch in an ARM emulator, it takes a very long
time to run all the click hooks, which directly affects how quickly we
can turn round CI tests; and I've also heard that various queries from
desktop infrastructure currently made by way of running click as a
subprocess can contribute as much as a second to application startup
time. This is obviously unacceptable and we need to do something
about it.
Not wanting to do a scorched-earth rewrite, my approach to this is to
rewrite hot parts of click in Vala (previously C, but I found that I
was writing too much error handling boilerplate by hand and Vala has
the right layer of abstraction here) and expose them as a "libclick"
library, using GObject in order to gain introspection support and thus
trivially have Python bindings available. This will allow me to
translate things gradually, and in particular it will let me leave the
existing rather comprehensive test suite in place with only minimal
adjustments, which will provide quite good assurance that I haven't
broken anything too seriously. By itself, it may well not speed
things up very much as the top-level /usr/bin/click program will still
be a Python script (at least for the moment), but we will be able to
gain significant improvements to application startup time shortly
afterwards with a few very small changes to packages such as upstart-
app-launch.
I had hoped to have an initial version of this in place well before
feature freeze, and have been coding frenetically over the last week
to try to achieve that. Unfortunately, the basic query functionality
that's top of the list for libclick requires essentially the whole
interwoven edifice of click.{database,hooks,user}, which is around
1000 lines of Python code, turning into around 2500 lines of Vala (it
would have been more like 5000 lines of C). If I were able to
separate out any particularly useful subset of this, I would, but I
don't think it's realistic. I also don't want to try to rush a
landing given how critical it is to the phone.
As such, I'd like to apply for a feature freeze exception for the work
described here. Based on my current rate of progress, I expect to
have something worth landing by around the end of next week.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/click/+bug/1282311/+subscriptions
More information about the foundations-bugs
mailing list