• Что бы вступить в ряды "Принятый кодер" Вам нужно:
    Написать 10 полезных сообщений или тем и Получить 10 симпатий.
    Для того кто не хочет терять время,может пожертвовать средства для поддержки сервеса, и вступить в ряды VIP на месяц, дополнительная информация в лс.

  • Пользаватели которые будут спамить, уходят в бан без предупреждения. Спам сообщения определяется администрацией и модератором.

  • Гость, Что бы Вы хотели увидеть на нашем Форуме? Изложить свои идеи и пожелания по улучшению форума Вы можете поделиться с нами здесь. ----> Перейдите сюда
  • Все пользователи не прошедшие проверку электронной почты будут заблокированы. Все вопросы с разблокировкой обращайтесь по адресу электронной почте : info@guardianelinks.com . Не пришло сообщение о проверке или о сбросе также сообщите нам.

HarmonyOS Next Type Analysis and De-Blurry—The Secret to Improve Performance by 30%

Lomanu4 Оффлайн

Lomanu4

Команда форума
Администратор
Регистрация
1 Мар 2015
Сообщения
1,481
Баллы
155
This article aims to deeply explore the technical details of Huawei HarmonyOS Next system and summarize them based on actual development practices.It is mainly used as a carrier of technology sharing and communication, and it is inevitable to miss mistakes. All colleagues are welcome to put forward valuable opinions and questions in order to make common progress.This article is original content, and any form of reprinting must indicate the source and original author.

As an old programmer who has experienced the performance bottleneck of Java/C++ virtual functions, he was shocked when he saw that HarmonyOS Next's Cangjie compiler could convert 90% of virtual calls into direct calls.Next, this article will reveal how this type analysis system enables object-oriented code to achieve performance close to C language.

1. Static type analysis system

1.1 Global Type Propagation Algorithm


The Cangjie compiler uses iterative data flow analysis method, and the process is as follows:


graph TB
A[Method Entry Hypothesis] --> B[Instruction Analysis]
B --> C[Type Status Update]
C --> D{convergence?}
D -->|No| B
D -->|Yes|E[generate type constraints]

Key optimization scenarios:

  1. When the factory method returns a specific type, it helps the compiler determine the actual type of the object.
  2. In the scenario where the configuration switch determines the implementation class, the compiler can make type inference based on the configuration.
  3. Stable type calls within the loop, and the compiler can optimize the calling process and improve performance.
1.2 Type annotation enhancement


Developers can use annotation-assisted compilers to perform type analysis:


@Closed // Prompt that the compiler has no unknown subclasses
class DatabaseDriver {
@Final // The prompt method will not be rewritten
func connect() { ... }
}

In HarmonyOS Next's database module, this annotation prompt increases the accuracy of inline decisions from 75% to 98%.

2. De-virtual practical strategies

2.1 Conservative de-blindness conditions


The compiler will trigger de-blurry optimization when the following conditions are met:

  1. The type of the call point is exactly known.
  2. The receiving object is not empty.
  3. The target method has not been rewritten.
  4. The call frequency exceeds the threshold (PGO, Profile - Guided Optimization, analysis-based optimization).

For example:


interface Renderer {
fun draw()
}
class OpenGLRenderer : Renderer {
fun draw() { ... } // The actual only implementation
}
// Optimized equivalent code
val renderer: Renderer = OpenGLRenderer()
renderer.draw() // Directly call OpenGLRenderer.draw()
2.2 Performance comparison data

SceneVirtual call(ns)Direct call(ns)Accelerating ratio
Single call3.20.84x
Call within the thermal cycle280 (including branch prediction failure)654.3x
Cross-device virtual call15 (including serialization)3.2 (static binding)4.7x
3. PGO boot optimization

3.1 Type profile acquisition


Examples of data collected during runtime are as follows:


// profile data format
Call Point #15:
OpenGLRenderer: 2876 times
VulkanRenderer: 12 times
null: 0 times
3.2 Multi-level optimization strategy

Optimization levelConditionsMeasures
L1Single implementation classDirect call+inline
L22 - 3 implementation classesConditional judgment + inline
L3Multiple implementation classesReserve virtual table calls

Practical case: In the graphics rendering pipeline, 95% of draw calls are optimized by L1, 4% of material-related calls are optimized by L2, and 1% of plug-in renderings use L3 virtual calls, ultimately achieving an overall performance improvement of 31%.

Infrastructure enlightenment: In the distributed UI framework of HarmonyOS Next, we split the core interface into the basic method of @Closed and the open extension method, so that 90% of the call links are completely de-blind.It should be known that the key to the balance between performance and scalability lies in architecture design, not relying on runtime "magic".


Пожалуйста Авторизируйтесь или Зарегистрируйтесь для просмотра скрытого текста.

 
Вверх Снизу