Customizations which "cost" the most in performance

So the single biggest factor that affects performance is how Sugar is used. A "costly" customization is not a big deal if it is only used rarely.

For example, certain kinds of Reports can be very costly in terms of performance.  Instead of having users run expensive Reports during business hours, you could set them up as scheduled reports that are run early in the morning and are delivered into user e-mail inboxes.

But specifically to your question, I would point out two customizations that you would want to avoid. There are others for sure.

You want to avoid what I call "subpanel creep" which is continually adding new subpanels to modules over time.  Each subpanel introduces an incremental cost (more SQL queries) to loading a single record view. This was discussed recently on the Sugar Developer Blog.

https://developer.sugarcrm.com/2016/02/29/addressing-subpanel-creep-in-sugar-7-7/

Time consuming processing in Logic Hooks.  Logic Hooks run synchronously, so you want them to run quickly so that the UI remains responsive for the user.  If you have a time consuming process, then move the "logic" for the logic hook into a Sugar job that gets placed on the job queue when the hook is fired.

https://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_7.7/Architecture/Job_Queue/Jobs/Queuing…

A couple of additional thoughts to Matt's comments..

1. Increasing the default ListView records from the default 20 records per page will affect performance of the ListView. It is generally recommended that you do not increase this value, although I've seen acceptable performance with 40 - 50 records per page.

2. Extensive use of SugarLogic enabled fields can also effect the time it takes to display a record. The most egregious case I recall seeing was one with 40+ SugarLogic enabled fields, which in turn caused Sugar (6.5 at the time) to take over 4 mins to display a record.

3. Using custom fields where a custom module is more appropriate. I shared some further thoughts on the fields issue here: What is the limitation on the number of fields you can add to a module?

4. Sorting ListView data on non-indexed fields can also degrade performance. This is something folks will usually encounter if they add custom fields to a module and its ListView, then choose to sort the data based on one of those fields.

5. One of the quickest ways to introduce performance problems though a customization is via a custom ACL and/or Visibility class. In the case of the latter, it permits you to literally rewrite the SELECT statements Sugar uses in the ListView (and other places). If you are not careful, you can easily introduce all kinds of inefficiencies through that process.

Those are some of the more common items we see out on the field.

A couple of additional thoughts to Matt's comments..

1. Increasing the default ListView records from the default 20 records per page will affect performance of the ListView. It is generally recommended that you do not increase this value, although I've seen acceptable performance with 40 - 50 records per page.

2. Extensive use of SugarLogic enabled fields can also effect the time it takes to display a record. The most egregious case I recall seeing was one with 40+ SugarLogic enabled fields, which in turn caused Sugar (6.5 at the time) to take over 4 mins to display a record.

3. Using custom fields where a custom module is more appropriate. I shared some further thoughts on the fields issue here: What is the limitation on the number of fields you can add to a module?

4. Sorting ListView data on non-indexed fields can also degrade performance. This is something folks will usually encounter if they add custom fields to a module and its ListView, then choose to sort the data based on one of those fields.

5. One of the quickest ways to introduce performance problems though a customization is via a custom ACL and/or Visibility class. In the case of the latter, it permits you to literally rewrite the SELECT statements Sugar uses in the ListView (and other places). If you are not careful, you can easily introduce all kinds of inefficiencies through that process.

Those are some of the more common items we see out on the field.

Thanks Matt

Thanks Angel, good pointers.

Extending a bit on point 2 of Angel: Not only the amount of Sugar Logic enabled fields can potentially affect performance but also if you have a few ones with a very large formula. If the formula is so complex that it has hundreds of lines of nested Sugar Logic that needs to be parsed often times a different approach like a logic hook is more effective ( Keep Matt's recommendation in mind though)