Improving general performance

[ErikBjare]

This has become a lot more important to me as of starting building the Android app.

I'm going to be running Lighthouse (the "Audit" tab in Chrome to evaluate performance, specifically on the Home view and the Activity view).

This was enlightening: https://checklyhq.com/blog/2018/08/how-we-got-a-100-lighthouse-performance-score-for-our-vue.js-app/

[ErikBjare]

Might have been fixed to an extent by #123

[xylix]

I did some research since I've found the 1-3second load times on localhost annoying, especially for large datasets. Do you think the problem is server- not frontend side for large (1+ months) buckets?

Anyway, the case is that having 1 a month bucket loaded does cause performance issues and CPU hogging. There's a "WARNING: infinite loop in redraw?" on the web console when viewing timeline which could be related.

I started following the instructions anyway for the heck of it and webpack-bundle-analyzer revealed aw-webui does load quite a bit of JS:

Lighthouse revealed some accessibility and loadtime issues on slow networks but slow network conditions is a mostly irrelevant problem when serving locally.

activitywatch-lighthouse.zip

@ErikBjare By the way, is the mobile version available somewhere?

[ErikBjare]

@xylix The Android app is developed in https://github.com/ActivityWatch/aw-android

Having a large JS bundle shouldn't be that much of an issue since it's served locally, but parsing JS can still be quite slow so might introduce some slowness in initially loading the web UI (especially on mobile), but not when it comes to waiting for queries to complete.

Almost all performance issues relating to large datasets are due to the server being slow to process the queries. aw-server-rust is much much faster in this regard, and since we're planning on migrating to it in the near/mid-term it'll solve itself. See ActivityWatch/activitywatch#331 for progress on that.

The Android app already uses aw-server-rust so there things aren't as bad on the server-side performance-wise, but since it also generates far more events (since every activity change generates an event) and runs on slower hardware it can sometimes feel slow as well.

There's a "WARNING: infinite loop in redraw?" on the web console when viewing timeline which could be related.

This is specific to the timeline and has always been that way. It appears to have been fixed in a recent release of vis-timeline (visjs/vis-timeline#17), so all that's needed to get rid of it might be to update that module (feel free to try it out!).

See the new issue I created for this particular task: #170

[xylix]

Okay cool. I'll try looking into updating to vis-timeline.

Thanks for the link to the rust-server progress. Seems like it's going to be a great upgrade.

Also it seem's activitywatch's integration test's don't have any UI tests in them. Is there an issue for adding them? I could look into adding some actual "initialize server, click buttons in ui, see that timelines / other things are displayed correctly" style tests if it would be useful.

[ErikBjare]

The reason for there not being any UI tests is that we don't have many UI related bugs and maintaining UI tests is a lot of work. I'd like to keep it that way for as long as possible.

It's pretty quick & easy to manually check that everything works as intended, so automating it doesn't have any significant benefit.

[johan-bjareholt]

This is an never ending issue, could we please split it into new separate issues such as "lowering bundle size" or "audit web-ui performance"?

[xylix]

Good idea @johan-bjareholt , I agree we should split this into better actionable chunks