<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kongtong · Mobile performance testing</title><description>Kongtong&apos;s mobile performance testing system: porting benchmarks to phone platforms, watching what the scheduler and clock frequencies do, and laying out the process and the numbers. Currently mostly SPEC CPU and Geekbench ports and performance measurements on HarmonyOS.</description><link>https://kongtong-bench.com/</link><language>en</language><atom:link href="https://kongtong-bench.com/en/rss.xml" rel="self" type="application/rss+xml"/><item><title>Implementing the SPEC test executor on HarmonyOS</title><link>https://kongtong-bench.com/en/posts/spec-executor-harmonyos/</link><guid isPermaLink="true">https://kongtong-bench.com/en/posts/spec-executor-harmonyos/</guid><description>The compute code of a SPEC workload is only one part of the test system. Once it lives inside a HarmonyOS app, inputs still have to be prepared, an execution environment set up, lifecycles controlled, time measured, output checked, and all of this linked into a result that can be re-examined. In our SPEC CPU2017 and CPU2026 apps these duties sit in the executor: ArkTS manages tasks, the native layer runs the workload, and the validation layer decides whether a result may count.</description><pubDate>Wed, 28 Oct 2026 13:15:00 GMT</pubDate><category>HarmonyOS</category><category>SPEC CPU</category><category>test executor</category><category>timing</category></item><item><title>Porting the GFXBench graphics tests to HarmonyOS</title><link>https://kongtong-bench.com/en/posts/gfxbench-harmonyos-port/</link><guid isPermaLink="true">https://kongtong-bench.com/en/posts/gfxbench-harmonyos-port/</guid><description>When bringing GFXBench&apos;s Aztec Ruins graphics workload into a HarmonyOS app, we split the work in two: ArkTS handles test selection, asset preparation, the run page and saving results, while the native layer owns the graphics context, scene initialization, the render loop and scoring. The two sides exchange test descriptions and results over NAPI and connect to the system display path through the NativeWindow provided by XComponent.</description><pubDate>Wed, 28 Oct 2026 13:10:00 GMT</pubDate><category>HarmonyOS</category><category>GFXBench</category><category>graphics</category><category>porting</category></item><item><title>MemStorageBench: measuring memory bandwidth and storage throughput on HarmonyOS</title><link>https://kongtong-bench.com/en/posts/memstoragebench-harmonyos/</link><guid isPermaLink="true">https://kongtong-bench.com/en/posts/memstoragebench-harmonyos/</guid><description>MemStorageBench splits memory and storage testing into two independent workloads: memory bandwidth measures the data traffic produced by a fixed copy workload, and sequential storage measures the throughput of a fixed file under continuous reads and writes. The UI shows rate, elapsed time and validation status, and every result keeps its workload, units and measurement method.</description><pubDate>Wed, 28 Oct 2026 13:05:00 GMT</pubDate><category>HarmonyOS</category><category>memory bandwidth</category><category>storage throughput</category><category>benchmark</category></item><item><title>MonitorHarmony: implementing on-device performance monitoring for phones</title><link>https://kongtong-bench.com/en/posts/monitorharmony-implementation/</link><guid isPermaLink="true">https://kongtong-bench.com/en/posts/monitorharmony-implementation/</guid><description>While running graphics tests or everyday apps, we want to see frame rate, CPU frequency, memory and power change right on the phone, and keep a record of the whole run. MonitorHarmony splits this into three paths: collecting data from the system and the target app, publishing state to the main UI and a floating window, and saving the complete session to produce history charts.</description><pubDate>Wed, 28 Oct 2026 13:00:00 GMT</pubDate><category>HarmonyOS</category><category>performance monitoring</category><category>floating window</category><category>MonitorHarmony</category></item><item><title>How the PC side builds a high-performance environment for HarmonyOS tests and keeps the device awake</title><link>https://kongtong-bench.com/en/posts/harmonyos-pc-performance-screen-awake/</link><guid isPermaLink="true">https://kongtong-bench.com/en/posts/harmonyos-pc-performance-screen-awake/</guid><description>Before a test, the PC-side HdcPerfController starts SP_daemon on the device over HDC, opens a high-performance capture session with -lockfreq and manages screen wake: protocol commands, keepalive and stop order, recovery records, plus 16 independent frequency snapshots and a two-hour screen-timeout override measured on the SGU-AL10.</description><pubDate>Wed, 28 Oct 2026 11:08:00 GMT</pubDate><category>HarmonyOS</category><category>phone testing</category><category>HDC</category><category>SmartPerf</category><category>high performance</category></item><item><title>Single-core scheduling on HarmonyOS: making the core selection reach the compute workload</title><link>https://kongtong-bench.com/en/posts/harmonyos-single-core-scheduling/</link><guid isPermaLink="true">https://kongtong-bench.com/en/posts/harmonyos-single-core-scheduling/</guid><description>When running single-core tests on HarmonyOS, the core chosen in the UI has to reach the compute thread through the call chain. This article records how QoS, sched_setattr/uclamp and affinity requests are issued and read back, the runtime maintenance and restore strategy of each benchmark, the build configuration, and measured single-core curves of SPEC CPU2017/2026 and Geekbench 6/7 on the SGU-AL10.</description><pubDate>Wed, 28 Oct 2026 00:00:00 GMT</pubDate><category>HarmonyOS</category><category>scheduling</category><category>single-core</category><category>SPEC CPU</category><category>Geekbench</category></item></channel></rss>