-
Notifications
You must be signed in to change notification settings - Fork 0
faster renders (I think) #49
Comments
I spent some time testing this last night. I didn't happen to see any improvement when doing a full from-scratch rebuild on either 7.6 BC or 7.7 BC. In the case where I do a full build and then did But. Each of my pages is doing one or more I think there is no denying a 3x improvement in any one project! |
I think the fact that there's more than one more |
Yes, I made the change you suggested in #43: reuse a namespace (looking back I see that you also got nearly 3x performance from that change). I realized I could introduce an extra parameter to signal when it was safe to reuse the namespace. Good idea — thanks! |
In my admittedly minimal experiments with SQLite in Pollen, I found that the per-transaction costs of a SQL query were very high compared to the average Pollen computation. Unless each |
Actually, the multiple I will do some experimenting with threads and batching for sure. Will start another thread about bespoke caching in general when I have any results to share. |
Could you please point to a specific commit and/or summarize the changes that allowed for faster renders? |
I’ve been burned before by overconfidence (see: parallel processing). But today I had (what I hope will turn out to be) a genuinely good idea: to create a fast path for
raco pollen setup
andraco pollen render
that skips certain expensive luxuries that one really needs only during interactive development sessions with the project server (which will be as sluggish as always). For instance, rebuilding Beautiful Racket is now 3x faster. Try it and let me know if it improves your life (or the opposite).The text was updated successfully, but these errors were encountered: