測試CC2652R協調器模塊的發送速度，採用如下方法：向串口發送一條命令，程序調用zcl_SendCommand（最終是執行的Zstackapi_AfDataReq），執行完後，串口返回ACK。測試發現從串口發出命令，到ACK回覆，中間最長耗時20ms多。
仔細推敲，第一個耗時大戶是CC2652R的原廠開發板，TI的XDS110仿真器模擬UART，在SSCOM4.2上居然有10ms的延遲。其次就是出在執行Zstackapi_AfDataReq。TI的實時操作系統TI-RTOS中的應用程序調用Zstackapi_AfDataReq，應用程序會進入IDLE狀態，然後在協議棧的task開始運行。但是因爲協議棧的task的優先級比應用程序高，協議棧會先執行AF_DataRequest，這個時候要發送的消息已經被壓進了發送隊列。前面說過協議棧的優先級比應用程序高，因此AF_DataRequest雖然return了，但是協議棧的發送隊列裏面有要發送的無線數據幀，會切換到nwk_event_loop的NWK_DATABUF_SEND事件，然後再退回到應用程序的任務優先級。
但是在nwk_event_loop執行發送無線數據任務時，出現了很大的延遲。於是在nwk_event_loop的接口處理NWK_DATABUF_SEND事件時打斷點，在NV-read的時候，發現執行NWK發送時NV-Read連續讀了兩次ZCD_NV_NWK_ACTIVE_KEY_INFO，而且每次延時都是5ms。而無線數據從壓入TX-FIFO寄存器到從天線出來，耗時不到1ms。ZCD_NV_NWK_ACTIVE_KEY_INFO是用於無線收發時的AES加密解密，硬件AES也是很快的。這樣一來就造成一個搞笑的現象：每次無線收發，5%的時鐘週期是無線傳輸，5%的時鐘週期是AES加密解密，剩下90%是在查表。
然後參考了CC2530/CC2538最後一版協議棧（z-stack 3.0.2），裏面的NV程序裏新增了一個叫“hot item”的機制。ZCD_NV_NWKKEY，ZCD_NV_NWK_ACTIVE_KEY_INFO和ZCD_NV_NWK_ALTERN_KEY_INFO共三個item被設置成hot item。在zstack中，普通的NV-item都是在Flash中採用循環的方式一條一條的查找，當然很慢。但是Hot item就是把NV-item對應的flash地址記在RAM變量中，因爲對NV-item進行“寫”操作並不是真正寫flash，flash是不可能被修改的，只是改變NV-item對應的地址。那麼每次修改NV-item的時候RAM變量記錄NV-item的flash地址也會被刷新。
但是由於CC2652是彙集了藍牙，zigbee，thread好幾種協議棧，因此NV-RAM中又取消了hot item機制，需要手動重新加上。在nvocmp.c中的函數接口NVOCMP_findItem和NVOCMP_writeItem，加入對ZCD_NV_NWKKEY，ZCD_NV_NWK_ACTIVE_KEY_INFO和ZCD_NV_NWK_ALTERN_KEY_INFO的特殊處理即可。
優化後，Zstackapi_AfDataReq的return時間，從12ms降到1ms。