Editor is extremely slow

Hi,

we have a quiet large app with >260 components and editing fields and JS queries is slow and typed characters are delayed making it impossible to work.
I tried editing in Safari (with cleaned cache) instead of Chrome on macOS but this did not help.

Is there any solution to this?

Best regards,
Steven

1 Like

Hi Steven! I used to have the same problems when I started out. I don't think that there is any single "solution" except for trying to optimize in various ways. Here's a few questions I would ask:

  • Do I need all 260 components? Are there discrete sections of the workflow that can be split up into different apps?
  • Do all 260 components need to be rendered at once? For example, if you are pulling up a record, do you need input fields for every piece of data, or could you display the record as text and have an "edit" button that pops open a modal?
  • Do you have a ton of components that are using logic based off of other components, which in turn are using logic based off of other components, which are based off of other components, etc.? Could this be refactored? Could you store information in the variables storage, and have components render based off of that?
  • Are you giving the users more information than is needed in the workflow? Perhaps overfetching information? Or over displaying information?

In general, I've found that developing and using the app with the Chrome Task manager open is extremely helpful. Do some workflows, and see when memory usage spikes! Go piece by piece and figure out what your biggest offenders are, and take a step back and ask if they need to be there at all, and if they do need to be there, can they rely on less deeply nested chains of components?

Good luck!

1 Like

Yes, I have same issue with small app too. No attached events and keyboard events seem very delayed. Unable to determine what the cause is.

Same here... Editor is practically unusable on Safari (Mac M1 chip) and super slow on chrome. The app it self (less than 20 components) is very slow, a lot of errors in the console (404 to inexisting ressources css.map and stuff like that).

Same here. Seeing general slowness when editing moderately large apps on Chrome. And by moderately large I mean less than 20 components, including table(s) with a couple thousand rows of data.

@steven @mattkerouac @AAZ @maurizio

Hey there :wave:

@**MarkR **has a great list of questions here, really great way to break down app performance. I am also going to link our docs on Building performant Retool apps. If anyone would like 1x1 support figuring out why their specific app is slower than expected I would recommend reaching out to support either in chat or through email. Otherwise, a few questions I have are:

  1. Are you seeing the same in preview mode? Or is this editor specific?
  2. Does this happen for all of your apps?
  3. Are there times when this is better or worse than others?

Hi there!

I'm also having pretty major performance issues.

I have 7 total components running 3 queries on startup and it takes close on 20s to load. Running 2 queries one after the other takes almost 8s. I think that MySQL is especially slow (server is in Cape Town) but it was almost as slow when I used a CSV and I'm only using 269 rows. Google Sheets is a little quicker at around 0.5s per query. My production DB is 28 000 rows and 5x as many columns so I'm worried about speed when I go live.

If I moved to the self-hosted version do you think the speed would improve?

Thanks!

@marc

Hey! To dive into your specific setup I would definitely recommend reaching out to support :slightly_smiling_face: Otherwise, if you are seeing latency in the "execute resource" statistics for your queries then self-hosting should improve performance.

it is a shame ! I had so much potential for this application.. it is practically un-usable !! thing is there is no multi-page support so you must and will always have more than a dozen fields components whatever -- dragging them or whatever is a pain .. I gave up

I am satisified with new IDE performance, it's a very huge improvement.

I heard that the multi-page support will come 3 or 4months after.

2 Likes

my suggestion is to provide settings to disable or somehow reduce the amount of UI tooltips, helpers, etc. - in other words just get to the basics a little bit with fewer "things" that happen anywhere you move the mouse - it is usability vs performance balance
one massive improvement would be to enable a feature to disable clicks altogether while in edit mode and disable queries -
anyway still new

I've had some reports from my team that Retool editor gets super slow on Chromium on Linux. However it's relatively better for Chrome on Windows or MacOS.

I suppose the retool team hasn't really tested their IDE/editor on Chromium on Linux since less of your customers are using that. But I'd like to have some dev from retool actually test it out and see just how bad the performance can get.

Hi there! Thanks so much for sharing this feedback! We are currently working on a project to further improve the IDE performance, so I've passed this feedback along internally :slightly_smiling_face: Also, as @AnsonHwang mentioned, we are currently working on multi-page support, which should help with larger apps or more complex use cases

1 Like