portal 2024-04-17

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 ""}}}

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?

I tried using this value:

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

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.

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.

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

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.

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

💯 1

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?)

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

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.