portal

Alexander Kouznetsov 2024-04-17T18:37:27.838629Z

Do we track performance of portal? Yesterday I worked with a large map of 90K key value pairs and UI was quite slow. I also noticed that when sending data to the portal, it sometimes takes a while for it to appear in the UI. For example, by looking at a tap-list atom I can see that it contained some number of elements, but the UI was still empty. I’m curious if this is the result of recent changes to hashing. (It could as well be me overloading the system with big structures).

Alexander Kouznetsov 2024-04-22T19:14:18.445159Z

Looks like I cannot just specify this commit as a dependency. I’m getting Error building classpath. The following libs must be prepared before use: [djblue/portal]. How can I test this?

Alexander Kouznetsov 2024-04-22T19:14:54.684829Z

I tried setting it like this:

{:extra-deps {djblue/portal    {:git/sha "f686b286ad7c5e258c620d687b008a8f34774534"
                                :git/url ""}}}

djblue 2024-04-22T19:15:26.650769Z

I think you are looking for https://cljdoc.org/d/djblue/portal/0.55.1/doc/guides/git-dep

🙌 1
Alexander Kouznetsov 2024-04-22T19:49:00.700509Z

Here is what I’ve got. I have a symbol to symbol map of 97K elements. In 0.48.0, search works nearly instantaneous with less than 1 second delay (including the case when nothing is found). In the current master, the search takes more than 3 minutes to start reporting any results (when searching for something that doesn’t appear on the top of the map, if sorted). And sometimes the VSCode IDE shows a “Window not responding” message. I had to dismiss it a few times before it actually finally returned the results of something that was closer to the end of the map. Thoughts?

Alexander Kouznetsov 2024-04-22T19:51:55.495449Z

This old superfast search was a killer feature.

Alexander Kouznetsov 2024-04-22T19:52:13.547059Z

What were the situations when it was slow?

djblue 2024-04-22T20:21:03.771189Z

I tried using this value:

(def m
  (into
   {}
   (for [_ (range 100000)]
     [(gensym) (gensym)])))
And it seems to filter for 12345 in about a second.

djblue 2024-04-22T20:22:52.670919Z

Are you sure you are using latest? If I switch back to before my fix commit, it is very slow 👌

Alexander Kouznetsov 2024-04-22T20:27:40.162739Z

I have a clone of the latest master where I ran this prep command clj -X:deps prep :aliases '[:dev]' and which I added as a dependency with :local/root pointing at that clone’s root folder.

Alexander Kouznetsov 2024-04-22T20:28:24.345119Z

Hmm, maybe I’m overriding the version actually. Let me recheck.

Alexander Kouznetsov 2024-04-22T20:31:51.481309Z

I see portal’s src and resources on the classpath, so it should be accurate.

djblue 2024-04-22T20:33:05.717239Z

If you have both the local/root dep and the jar dep and the jar is earlier in the classpath, you might be getting the older main.js 🤔

Alexander Kouznetsov 2024-04-22T20:34:14.168559Z

Could vscode extension be the contributing factor?

Alexander Kouznetsov 2024-04-22T20:34:30.842589Z

That’s where I’m testing it.

djblue 2024-04-22T20:34:56.218119Z

Perhaps a little but it shouldn't be this much.

djblue 2024-04-22T20:36:33.090959Z

Here is a jar with the latest changes. You can replace the one at ~/.m2/repository/djblue/portal/0.55.1/portal-0.55.1.jar and see if that helps

Alexander Kouznetsov 2024-04-22T20:52:26.298169Z

Thanks, with this jar I indeed can see search completing in around 1 second. Feels much slower than how it worked in 0.48.0 but a significant improvement over 0.55.1. Thanks for fixing the problem!

Alexander Kouznetsov 2024-04-25T17:47:57.600929Z

Nice, thank you for performance improvements! I’ll wait for the next release to give it a try.

seancorfield 2024-04-17T18:49:14.230819Z

I would expect such a large hash map to take quite a while to build the UI for...

💯 1
djblue 2024-04-17T19:00:10.305239Z

Portal doesn't track performance internally, but that could be an interesting add. What are you hoping to do with that data structure in Portal once it's loaded?

Alexander Kouznetsov 2024-04-17T19:17:29.353739Z

I’d search for a particular entry in it.

Alexander Kouznetsov 2024-04-17T19:19:09.214939Z

Searching was also slow. First it would clear the results (which gave me wrong impression that my search entry isn’t found) but then they will slowly appear over time.

Alexander Kouznetsov 2024-04-17T19:19:46.129029Z

I might be wrong, but I think it used to work faster in the past.

Alexander Kouznetsov 2024-04-17T19:25:05.361479Z

Luckily I recorded a demo of it with 0.51.1 version and the search was snappy. The actual number of elements in that map was 110K entries. It was one of the main differentiators for me that I can now tap and search inside of the data so quickly.

Alexander Kouznetsov 2024-04-17T19:25:51.707649Z

I can try to replicate this in a bit with this and the current version and compare the results.

Alexander Kouznetsov 2024-04-17T19:29:51.228739Z

It was also previously showing the number of matches - but now it doesn’t seem to do it anymore (or maybe it just takes time to finish calculating?)

djblue 2024-04-17T20:01:12.263509Z

So I recently https://github.com/djblue/portal/commit/96bbfc14de9f07a050f053b5a64edb38224eef7f, which improved performance for me in a lot of cases but I think introduced other performance issues. I pushed https://github.com/djblue/portal/commit/be31963a7e324dc1160a88182e82c3c02a49ce27 which I think should fix your issue since we shouldn't even be telling react about a given value if we don't intend to render it. The main performance win was making filtering lazy which is why the count is static.

🙌 1
djblue 2024-04-17T20:02:47.417249Z

I tried the filtering with 100k rows and it is much better when using keep-indexed vs map-indexed 👌

🙌 2
Alexander Kouznetsov 2024-04-17T20:06:12.745299Z

Thanks! I’ll give it a try.

djblue 2024-04-25T06:52:50.650739Z

I think https://github.com/djblue/portal/commit/31d3486066924e900cda6d584103617e27df5088 should fix the remaining performance issues 👌

🙌 1