• The Art of System Performance for Engineers
  • Original post: The AI LAB
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: lhd951220
  • Proofreader: z0gSh1u plusMultiply0 kylinHolmes

Encountering system performance problems is an inevitable part of a software engineer’s career. Examples of common system performance problems are as follows:

  • Disk I/O: For example, loading application code and resources from disk
  • Network I/O: Loads data or images from the server
  • Interprocess calls: Implement single sign-on, or interact with the operating system

In Java, most of these problems are not immediately apparent when you write code. The abstraction of most disk IO methods, coupled with the implicit loading of classes, makes it look like it’s calling ordinary methods. In fact, most of the time, all of these issues (with the exception of network IO) run fast enough in informal local testing to go unnoticed. Code loads quickly because it is already in memory before it is run, and the process you call survives previous calls. For network IO, problems that are not detected because the network is too fast will also show up in the production environment.

Wouldn’t it be nice if engineers could “see” their calls slowing down?

thread

In general, applications need to maintain a frame rate of 60fps, or one frame every 16ms. To do this, the UI thread must update the UI in a time range of 0 to 16ms. Network IO typically takes several times as long as 16ms, which gives us two choices: split tasks in smaller slices, or let other processes perform the work and return results. In Java, the second option is implemented using threads.

There is a background thread to complete time-consuming tasks, the results of which need to be displayed in the UI. Therefore, data needs to be passed from the background thread to the UI thread. In practice, there may be several patterns:

  • The UI thread subscribes to events for the data.
  • The UI thread reads/polls data from the shared object.

The first mode is more powerful, but requires more work. The second model is more natural, but riskier. For example, throughout the application, the developer might need to know information about the current user. However, this information still needs to be loaded from disk when the application is started. This leads to an interesting situation where the developer blocks the UI thread while waiting for results to be generated from the background thread. Unfortunately, this pattern of making the UI thread wait for the background thread is more common than expected.

Wouldn’t it be nice if engineers could “see” them calling blocking methods?

trade-offs

Doing all the work on the UI thread is the easiest solution, and many times it works. In the real world, however, some tasks have serious performance problems. Most of the time, developers move most of the work to background threads.

It is usually better to read data directly from the results prepared by the background thread, except in cases where concurrent writes exist during the data read operation. Therefore, exclusive data access is guaranteed through synchronous operations.

Using exclusive access to read data directly from the results is usually fast, except for the occasional scramble for exclusive access to the data. Therefore, most of the time, developers will work on some tasks in request-response mode and let the UI thread subscribe to the results.

Changes to subscription data also require anticipatory planning, which adds more complexity for users to do the right thing.

Wouldn’t it be nice if engineers could provide a simpler pattern for implementing correct, efficient code?

While these challenges may sound daunting, here are some tips for engineers to overcome them:

  1. Provide run-time information to engineers to help them make better decisions when writing code, such as creating a plug-in that presents data.
  2. The prototype is a highly functional and readable Reactive/Redux-style UI.

There is no doubt that, no matter how hard an engineer tries, these systems challenges require some “soft” skills in addition to a “hard” background.

As an individual contributor, it is the engineer’s responsibility to bring their questions and concerns to the system review meeting. You may need to create a document to share with the administrator, suggest a topic you want to discuss, and follow up with submissions.

Don’t bring up a complex topic on a formal company-wide survey or in an all-hands meeting. Make sure you are discussing difficult issues with your manager. It’s all about mutual trust.

Export the product and let everyone know about it

Each engineer’s success is measured in different ways in different companies. But there is one thing that matters to everyone who wants to be recognized and rewarded. That is, exporting products or doing related systems development work for the infrastructure team. This should come up in self-examination and discussion: what has been delivered.

If you explain to your manager the challenges you face and how you overcame them, it will help him a lot. Maybe your manager needs reasons to help you nominate for a promotion. Help them find reasons.

Go to the next level

Don’t underestimate the value of the promotion process, and don’t forget to look for top performers in your organization. Other teams may already have senior engineers who have been nominated for promotion because of the criteria.

If you want a promotion – start working at the next level, take responsibility, and expand projects. You can’t wait for someone to tell you what to do. Move forward now, build your sense of responsibility, and recognition will follow.

What does the next level mean?

Most tech companies have a level of competence (they may call professionals “beginner,” “intermediate,” “advanced,” “expert,” or have some code for it, such as IC3-IC6). Some companies define career expectations: what you should do at each ability level. A rare career expectation is the “time to deliver” dimension.

For example, if a senior engineer can deliver feature X in two weeks, it might take three weeks for a mid-level engineer. If the organization wants to nominate mid-level engineers for promotion — they should not only deliver high quality work, but also work within the time frame of the next level.

Develop in a sustainable way

Most companies have two types of awards for outstanding performance. The first is bonus, and the second is promotion. A bonus is an extra reward for people’s performance over time. Promotion is recognition of their ability to move to the next level and their performance over time. These two rewards usually don’t come together. A good manager should find out if someone is working 24×7 hours and should consider marking them as not working at the next level.

No one can work 24×7 24/7, so your performance will decline in the future. Make sure you exceed expectations when you spend a reasonable amount of time on your work.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.