touch-packages team mailing list archive

[Daniel van Vugt <daniel.van.vugt@xxxxxxxxxxxxx>]

I think hashing (upstream hybris) is a better idea and we should jump to
that when possible. Although I just assumed we had no intention of
rebasing given the significant diff. If we can then we should. I don't
know what the performance diff to upstream is but upstream's hashing
should possibly be even better than the bsearch.patch.

bsearch.patch is a short-term solution and long term we should rebase
when possible.

** Summary changed:

- [android] Mir spends 12%+ CPU time in get_hooked_symbol (libhybris-common) comparing strings when it should be rendering
+ [android] Mir spends 12%+ CPU time in get_hooked_symbol (libhybris-common) comparing strings

** Changed in: libhybris (Ubuntu)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libhybris in Ubuntu.
https://bugs.launchpad.net/bugs/1343198

Title:
  [android] Mir spends 12%+ CPU time in get_hooked_symbol (libhybris-
  common) comparing strings

Status in Mir:
  In Progress
Status in “libhybris” package in Ubuntu:
  In Progress

Bug description:
  On the N4, Mir spends 12%+ CPU time in get_hooked_symbol (libhybris-
  common). Actually callgrind can't decide; it's somewhere between 12%
  and 46000% ;)

  So it's big. Looking at the hybris code, there's a rather large
  bottleneck that's obvious: get_hooked_symbol does a linear search
  (many times) of a large list of strings using strcmp alone. That's why
  22132 calls to get_hooked_symbol are yielding over 5 million calls to
  strcmp.

  Upstream hybris appears to have been modified to use a cache/hashing
  instead of the ugly linear search we have.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mir/+bug/1343198/+subscriptions