Opened 23 months ago

Closed 22 months ago

Last modified 4 months 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



Switched to beta1 for testing purposes using:

pkgman add$(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

Attachments (2)

profile_english.txt (82.1 KB ) - added by luroh 23 months ago.
profile_russian.txt (60.7 KB ) - added by luroh 23 months ago.

Download all attachments as: .zip

Change History (11)

by luroh, 23 months ago

Attachment: profile_english.txt added

by luroh, 23 months ago

Attachment: profile_russian.txt added

comment:1 by luroh, 23 months ago

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

Populating the list takes 3 seconds with English locale, 30 seconds with Russian.

Last edited 23 months ago by luroh (previous) (diff)

comment:2 by diver, 23 months 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, 22 months ago

Milestone: R1/beta1Unscheduled

comment:4 by apl-haiku, 22 months 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, 22 months 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, 22 months 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 22 months ago by apl-haiku (previous) (diff)

comment:7 by luroh, 22 months ago

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

Last edited 22 months ago by luroh (previous) (diff)

comment:8 by waddlesplash, 22 months ago

Resolution: fixed
Status: newclosed

Fixed in hrev52384 .

comment:9 by nielx, 4 months 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.