Appsheet performance: I need some expert help to optimize an Appsheet app.

I have been developing apps with Appsheet for about a year.  I have more than 30 years of experience as a programmer in different programming languages and Appsheet is my first no-code experience. I am very skilled at optimizing the code of the functions to the maximum, so I believe that all the functions I use are the minimum necessary expression.

The first apps I developed were simple and all good. I liked Appsheet because with imagination and creativity you can combine formulas, views, valid-if, show-if, display-if, actions and bots to get a lot of functionalities.  When writing formulas I always noticed the message "Note: This expression could impact performance.", and I always try to look for the simplest and simplest formulas. I have never had complaints about performance, but now I have developed a more complex app, with 18 tables, with several relationships between tables, several slices for filters by roles, calculated columns, and the client complains that the app takes a long time to load. And the truth is, it doesn't seem to me such a high level of complexity that the app is so slow to load.

I have been consulting all the Appsheet documentation regarding the subject, and some related posts in the forum, and I understand the recommendations...but I find myself with the problem that I do not see clearly how to optimize the functionalities that have been developed for the app, because the referenced tables are needed, the calculated columns are also needed, the filters to visualize or validate data are also needed, ..... I can go one by one and see alternatives, and test if the alternative improves performance, do speed tests for each change, but the truth is a very tedious, trial and error task.

Appsheet is very magical because it allows you to develop very good functionalities by combining the different elements (formulas, actions, bots, ...) but if you can't use all these combinations freely because it affects the performance .... Then I wonder if there is something wrong with Appsheet. For me it is important to see if I can solve the performance issue in an efficient and practical way, because if not I will have to look for another development tool.  That's why I ask if there is someone in the group who can explain how the app is built and can give me concrete and efficient recommendations to optimize performance.

……..

PREFIERO SI ES ALGUNA PERSONA QUE HABLE BIEN ESPAÑOL, YA QUE MI INGLÉS NO ES TAN BUENO Y NECESITO UNA COMUNICACIÓN FLUIDA PARA ESTE TEMA.

Solved Solved
6 29 1,265
1 ACCEPTED SOLUTION

Hola como estas. Desde mi experiencia (ojo no se un solo lenguaje de programación) he estado desarrollando con appsheet hace tiempo y me he topado con el mismo problema. De tanto analizar casos he descubierto una forma.

Por ejemplo, cuando tienes que colocar una condición que produce esto:  "Note: This expression could impact performance." es porque la expresión utilizada puede ser un filtro que devuelve una lista. Siempre estas expresiones es mejor no repetirlas. Por ejemplo. Si haces un Show If y en cada Show If debes colocar una expresión que impacte en el performance, deberás considerar crear una columna virtual que tenga la expresión que impacte. Esa columna tendrá un nombre y se calculará una vez y no en todas las columnas. En todas las columnas apuntas al resultado de la columna virtual que creaste y vas a lograr una optimización en el camino de la lógica de tu app. Esto es valido para todos los casos. 

Supongamos que tienes una tabla con un montón de registros y todos deben ser visibles si una de las opciones es válida y, si esa opción es válida solo si no se repite, tendrás que crear un filter que impida las repeticiones. No puedes estar escribiendo el mismo filter en el valid if y en los show if, etc., etc. Para eso haces una virtual column una sola vez y apuntas a ella en las condiciones.

Si tienes que hacer, por ejemplo, expresiones grandes y en ellas existen múltiples condiciones que a su vez se repiten en otros cálculos, te recomendaría simplificar la expresión, creando pequeñas porciones de la expresión, concentradas en pequeñas expresiones que estén dentro de esas virtual columns.

Las virtual columns no deberían impactar en la app ya que no se cargan en cada columna sino una sola vez por vuelta. 

Espero que lo que te diga te sirva. Saludos 

 

View solution in original post

29 REPLIES 29

Il impacto que tendría el número de tablas en el tiempo de sincronización es mínimo; tengo una app con 85 tablas hoy y creciendo, cientos de vistas, casi mil acciones, y decenas de miles de filas en varias tablas en Google Sheets. Está muy bien que estás pensando en la optimización de tus expresiones, siempre que tengas en cuenta cómo se se interpretarían estas expresiones en el backend de AppSheet, cuándo se evaluarían los cálculos, con qué frecuencia y sobre qué tamaño de dataset se ejecutaría cada expresión. 

Entiendo que has leído bien la documentación relevante de AppSheet, y por lo tanto lo primero que te aconsejaría es de echar un vistazo al Performance Monitor que te dirá con un buen nivel de detalle cuáles son las tablas que requieren más tiempo y más importante las columnas virtuales que consumen la mayoría del tiempo de sync. Así puedes identificar las prioridades donde tendrías que actuar. 

En muchos casos, no hay mucho margen de maniobra y hay que pensar en cómo hacemos una estructura de datos mejor. No solo problemas de rendimiento, pero también hay otros problemas que no se pueden evitar ni aliviar con una mala estructura. Por eso diría que lo más importante antes de empezar con cualquier app es tener un diseño con un buen *data modelling* que sigue las buenas prácticas del diseño de una base de datos relacional. Es el problema que tiene yo diría la mayoría de creadores de apps de AppSheet. No hay mucha programación involucrada; es una plataforma low-code; pero es una base de datos, y sin un buen entendimiento de los básicos de funcionamiento de un RDBMS, no se puede crear una app escalable que podría crecer conservando su eficiencia. 

Es lo que te puedo aconsejar de manera general. Propongo que empieces mirando estas dos pistas: El Performance Analyzer y el Data Modelling de tu app.

Gracias por tu respuesta Joseph. No creo que sea el modelo de datos, llevo mas de 30 años trabajando modelos de bases de datos relacionales y es una base de datos sencilla.

Ya he estado mirando también el Performance Analyzer, pero no me da pistas claras.

 

Thank you @Joseph_Seddik for you details.  It helps me better understand the capacity of the solutions as it makes me nervous how far I can push it.  85 tables and 100+ views on a single appsheet is significant accross 1000 shares so I am impressed.  Currently my max usage is 200 concurent users daily and climbing of which I am watching closely.   If you have anymore max thresholds you can share, that would be fantastic.

I too not unlike @evadeumal , plenty enough years of large application dev but currently only 7 months on Appsheet.

Thanks again.

Mi consejo es evitar las columnas virtuales lo más que puedas.
Estoy seguro de que si cambias columnas virtuales (que no necesariamente tengan que serlo) a columnas físicas mejorarás drásticamente los tiempos de sincronización. 

Gracias por tu respuesta. Sí, es una de las cosas que quería analizar, aunque tampoco creo que pueda cambiar muchas columnas. Voy a ver.

Como estás @Kabuliño ? Espero que muy bien hermano!!! No tengo dudas de que es así, que hay que reducir el uso de virtual columns pero hay casos en que si es válido. Por ejemplo en que las condicionantes como Show If, Valid If, etc., tienen espacios donde van expresiones. Estos espacios ser comportan como columnas virtuales ya que realizan un cálculo si hay algo en ellos. SI tu repites este cálculo en todos esos espacios con una misma expresión, lo que estás haciendo es hacer todas esas veces el mismo cálculo cuando en realidad lo que conviene es tener una virtual column creada con ese cálculo y apuntar a ella cada vez que la neceesites. De esa forma, reduces ampliamente el impacto en el perfromance de la aplicación. 100% comprobado por mi.
Si tienes expresiones de filtrado, por ejemplo, no existe mejor solución que hacerla una sola vez en una virtual column y apuntar desde todas las columnas reales en las que la necesites a esa virtual column que se calcula solo una vez y no en todas las columnas reales. Si bien la columna real almacena el dato, no olvides que el cálculo debe realizarse y estamos tratando de reducir el impacto. @evadeumal 

@Gustavo_Eduardo  estoy de acuerdo contigo, fuí muy general al aconsejar evitar las columnas virtuales y es verdad que todos los lugares donde es posible tener una fórmula tienen un impacto en cuanto a procesamiento con el dispositivo o sincronización con el servidor aunque me parece que esto varía ya que en algunos lugares se computa todo el tiempo (VC, Formula, Format Rules) y en otros solo se computa en un momento determinado (Valid if, suggested values, initial value).
Me parece lógico lo que comentas sobre no repetir fórmulas en cada campo que requiera la misma fórmula, sin embargo si mal no recuerdo me he topado con ocasiones en las que usar una VC en un título da un delay en la actualización del contenido (por lo menos en la parte gráfica) a diferencia de cuando le doy la fórmula completa al título, probablemente por el tipo de fórmula o no sé, tendría que intentar recrear los casos.



@Gustavo_Eduardo wrote:

creo que lo ideal sería crear un protocolo de producción no code con appsheet.


Sin duda sería de muchísima ayuda tener un documento al cual recurrir en busca de buenas prácticas para appsheet, a pesar de que appsheet tiene una documentación no se explican conceptos, protocolos o técnicas necesarias para lograr ciertas funcionalidades sin que comprometan los tiempos de sincronización o procesamiento, en este sentido la comunidad ha funcionado como una muleta para que appsheet siga andando. 

Perfecto. El aporte que dejas es muy bueno. De eso se trata, de sumar!!! me llevo tu experiencia y la tendré en cuenta Irmao! un abrazo desde Argentina

I would say you would need to have someone to check your app. Otherwise our suggestions would be only in general level.. and it sounds those you already know.

Hi Aleksi, 
Yes indeed, you are right. I really appreciate all your suggestions and your help, but what I need is someone to guide me checking my application, as I need to solve fast. I don't have so much time for testing, and it's easier guided by someone who already has experience. 

At first we would need to know your sync time and what's the goal. I assume you are using real database with your app and you have at least AppSheet Enterprise Standard subscription, right? Then.. how much data (rows) you have in these 18 tables at this moment? How much the sync time has increased from the beginning (approx.). With these basic details we could have an idea from your app.. and have more questions and ideas.

Thanks Aleksi.   Yes, I'm using real data, but  the app is now testing and there are not more than 1000 rows, then I know that the problem is not the amount of data. No, I don't have Enterprise suscription, this app is in a Publisher Pro subscription. Is this important o relevant for the performance? 

So.. what is your sync time at this moment? What do you think it should be?

Appsheet can easily handle these tables mentioned above. You can show us the virtual columns used in your app to understand more about it.

Here is one of my apps and its statistics.

Screenshot 2023-08-07 at 9.31.00 PM.pngTOTAL OF HYDRA.png

Here is the sync speed. Sometimes used to go below 5sec to load depending on network and time app is opened.

Screenshot 2023-08-07 at 9.35.20 PM.png

Thanks Rifad

Bueno, entonces pediría a alguien que quiera revisar conmigo la app y la base de datos para comprender rápidamente qué puntos podrían mejorar el rendimiento.  Puedo pagar algo por ese asesoramiento. Gracias

You could find someone on Upwork or Fiverr.

Thank you all for your responses. I still don't know exactly how I will approach the performance issue, but all of your suggestions have been helpful. Thank you very much

Hola como estas. Desde mi experiencia (ojo no se un solo lenguaje de programación) he estado desarrollando con appsheet hace tiempo y me he topado con el mismo problema. De tanto analizar casos he descubierto una forma.

Por ejemplo, cuando tienes que colocar una condición que produce esto:  "Note: This expression could impact performance." es porque la expresión utilizada puede ser un filtro que devuelve una lista. Siempre estas expresiones es mejor no repetirlas. Por ejemplo. Si haces un Show If y en cada Show If debes colocar una expresión que impacte en el performance, deberás considerar crear una columna virtual que tenga la expresión que impacte. Esa columna tendrá un nombre y se calculará una vez y no en todas las columnas. En todas las columnas apuntas al resultado de la columna virtual que creaste y vas a lograr una optimización en el camino de la lógica de tu app. Esto es valido para todos los casos. 

Supongamos que tienes una tabla con un montón de registros y todos deben ser visibles si una de las opciones es válida y, si esa opción es válida solo si no se repite, tendrás que crear un filter que impida las repeticiones. No puedes estar escribiendo el mismo filter en el valid if y en los show if, etc., etc. Para eso haces una virtual column una sola vez y apuntas a ella en las condiciones.

Si tienes que hacer, por ejemplo, expresiones grandes y en ellas existen múltiples condiciones que a su vez se repiten en otros cálculos, te recomendaría simplificar la expresión, creando pequeñas porciones de la expresión, concentradas en pequeñas expresiones que estén dentro de esas virtual columns.

Las virtual columns no deberían impactar en la app ya que no se cargan en cada columna sino una sola vez por vuelta. 

Espero que lo que te diga te sirva. Saludos 

 

👍  Waw! Muchas gracias Gustavo Eduardo,  este tipo de recomendaciones es lo que necesito.  Claro que me sirve, y mucho.  Voy a revisar mis fórmulas teniendo en cuenta lo que me explicas.

Gracias!

SALUD POR ESO! LO QUE NECESITES!

Hello again,
One more question. I have several fields of type LIST with formula REF_ROWS because there are quite a few parent-child relationships, and I also have different fields of this type defined for different slices, because each slice has its own view, with its own Related rows.

Does this type of fields affect the synchronization time when loading the app?
I If so, is there any alternative to not using so many LIST / REF_ROWS fields?
Thanks

It totally depends on how the app is structured and what's the goal. If you don't need any virtual column's calculation, you could use Enum (or Enumlist) with the base of Ref. It will give you a list for the dropdown, but you can still use for example derefs.

Propongo que comencemos por algun lado. Siempre hay alguien con este tipo de dudas y creo que lo ideal sería crear un protocolo de producción no code con appsheet. Me parece de suma utilidad y debería ser un documento editable y consultable. No se si Appsheet lo creará alguna vez pero quienes estemos interesados en resolver situaciones como estas, de muchísima utilidad sería un documento así. 

Te dejo otro tip. Es preferible que crees una virtual column en tu tabla y apuntes a ella en las reglas de formato (format rules) a que crees la expresión en la regla de formato directamente. Esto reduce de forma abismal la exigencia para tu app.

Un tip muy interesante, gracias.

Y la propuesta de hacer como una guía con estos tips sería muy muy útil.  Me parece una propuesta genial! 

Hola, muy interesante lo que comentas. Yo utilizo muchas Valid If, Show If y Format Rules iguales para varias columnas que son del tipo si/no (true/false). A que te referís con que "apuntes"? O si me podrías dar un ejemplo mas detallado, me serviría para entender. Muchas gracias de todas formas!

Si estás editando web y necesitas que vaya más rápido, te recomiendo reducir la memoria utilizada. Esto es posible configurando el editor. En la burbuja de usuario "arriba a la derecha" pinchas y entras en el "Editor Setting" y ahí, donde dice cuántos "deshacer" quieres por defecto, reduce la cantidad en caso que no seas habitué de esta funcionalidad.

Hola Eva. A raíz de estas cosas he creado un protocolo estándar de nomenclatura para AppSheet que por ahora se encuentra en Apple Books. Te dejo el link donde dejé ambas referencias aquí en un post de la comunidad. Se encuentra en español y en inglés. Estoy constantemente evolucionándolo. No quiero hacer 10 versiones de un libro sino un solo libro vivo. En fin, tiene un capítulo sobre columnas virtuales donde explico cómo yo optimizo mis aplicaciones al punto de reducir tiempos de guardado y aumentar la velocidad de sincronización.  Si te sirve héchale un vistazo. 

 

Hola Gustavo, 

Genial! Gracias lo miraré y lo iré siguiendo, parece muy útil y práctico.

 

Top Labels in this Space