Opened 6 years ago

Closed 6 years ago

Last modified 4 years ago

#14513 closed bug (fixed)

[HaikuDepot] is extremely slow at populating the package list

Reported by: diver Owned by: stippi
Priority: normal Milestone: R1/beta2
Component: Applications/HaikuDepot Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

hrev52295+70+dirty.

Switched to beta1 for testing purposes using:

pkgman add https://eu.hpkg.haiku-os.org/haiku/r1beta1/$(getarch)/current

and I'm experiencing an extremely slow package list population in HaikuDepot. 20 packages per second. Also decorations (icons, images) don't show up. Created a separate issue about it https://github.com/aplgithub/haikudepotserver/issues/153

Attachments (2)

profile_english.txt (82.1 KB ) - added by luroh 6 years ago.
profile_russian.txt (60.7 KB ) - added by luroh 6 years ago.

Download all attachments as: .zip

Change History (11)

by luroh, 6 years ago

Attachment: profile_english.txt added

by luroh, 6 years ago

Attachment: profile_russian.txt added

comment:1 by luroh, 6 years ago

No network interface present, HaikuDepot working purely with cached data. Outputs from 'profile -f -i 100 HaikuDepot' attached.

Version 0, edited 6 years ago by luroh (next)

comment:2 by diver, 6 years ago

I have a bit different stats in VMware Fusion with 2 cpu's:
5 seconds with English locale, 110 seconds with Russian.

comment:3 by waddlesplash, 6 years ago

Milestone: R1/beta1Unscheduled

comment:4 by apl-haiku, 6 years ago

I am checking this with a test instance of HDS running locally with the following locales;

  • English
  • German
  • Russian

The time from HaikuDepot launch through to completed display of the main window seems to be the same for me across all three locales?

comment:5 by luroh, 6 years ago

Well, the word "completed" may be a bit ambiguous in this case. Pay attention to the small package counter on the left hand side. During my testing, it was way slower to finish counting the packages when using Russian locale instead of English.

comment:6 by apl-haiku, 6 years ago

The problem actually (mostly) seems to be with this little text field because it is constantly rendering the value and figuring out the plurals which I had previously learnt from Diver are more complex in Russian language than is the case in English.

static BStringFormat format(B_TRANSLATE("{0, plural, "
  "one{# item} other{# items}}"));

I can see that this can be sped-up by avoiding deriving this string many times; at least a couple of times for getting the size of the BView and once for rendering the text. This is achieved by not allowing the field to be dynamic, but by pre-choosing a 'sensible' upper limit to the count of packages for this label and fixing the size of the field. This is proabably acceptable for now and the speed seems to be quite a bit better. It will be good to hear how this goes for you.

An even better solution would be to delay the rendering of the label and to update it every second. However this is a bigger change.

Last edited 6 years ago by apl-haiku (previous) (diff)

comment:7 by luroh, 6 years ago

Patch set 1 in Gerrit fixes the problem with Russian for me (gcc2h, master).

Last edited 6 years ago by luroh (previous) (diff)

comment:8 by waddlesplash, 6 years ago

Resolution: fixed
Status: newclosed

Fixed in hrev52384 .

comment:9 by nielx, 4 years ago

Milestone: UnscheduledR1/beta2

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

Note: See TracTickets for help on using tickets.