This article focuses on the performance issues I encountered in this recent project and how I optimized them.

Performance problems encountered

Room component performance

The recent project is mainly about real estate related management system, in which a table component is used to describe the room model. The performance problem mainly lies in the rendering effect of more than 1000 rooms. For specific room component effect, please refer to the article “Talk about the two years when I became the front end”.

The following are the main performance issues with this component:

  • When more than 1000 rooms are generated, it takes too long to render an operational room table from the room unit, room number, floor and other information filled in in step 2
  • When the number of generated parking Spaces exceeds 2000, it takes too long to click the “All” button to select all rooms until the whole selection effect is displayed

The SQL query takes a long time. Procedure

In a certain project in the past, there was an SQL report statistics, the execution time reached 4 minutes, poor user experience, need to be optimized.

The idea of optimization

The core idea of performance optimization is to find out the key points that affect performance, and then choose a better way to solve the problem. Therefore, during performance optimization, it is necessary to analyze the parts of the code that affect performance, and then targeted to solve the problem.

Room component optimization process

Generate the room

Because it is a front-end function, the rendering performance of the room component includes the processing time of the logic part of the code and the processing time until the rendering is complete. When trying to optimize this component, I tried to record the Performance overhead of the entire process by using Google Browser Performance, but the result set of the entire 4-minute snapshot is so dense that it is hard to find the key points, at least for now.

After the failure of the Performance analysis, I tried to analyze the Performance cost step by step. In the method needed to generate the room table, I used time/timeEnd to record the processing time of the whole method, and found that the Performance was still ideal, so the problem was mainly in the rendering process.

The project uses Vue. When there is no problem with the performance of the code, I start the timing with time at the end of the generation method and end the timing with timeEnd in the updated method, so as to record the code from the completion of processing. Then I continued to delete the attributes on the tags in the template, delete tags and other operations, and analyzed which template affected the performance. It was found that the ref attribute on el-Input, as well as the entire el-Input, particularly affected performance, and the performance problems were solved by simulating this input effect with div tags and contenteditable attributes.

Parking is selected

The rendering performance of the parking spot selection effect is still to use time/timeEnd to record the overhead, then step by step analyze the code where the problem is, and then try other ways to avoid it. This question led me to write an article called “$Emit Doesn’t Always work that well”.

Optimize SQL

When optimizing report SQL, the performance of each SQL section is still analyzed. The key part that affects performance is found in the sub-query in SELECT, and then the performance problem is solved by connecting tables to achieve the same query function.

conclusion

In each of the three examples above, step by step/piece by piece analysis of the code to find the code that affects performance, and then choose a better way to implement the same functionality. So, knowing how to record performance overhead is a prerequisite. Second, after analyzing the key code, it is essential to know the better implementation. Finally, this idea of step-by-step analysis is common to all “debugging” processes.