contributed by < hankchang805
>
linux2020
queue_t
為了讓 q_insert_tail 以及 q_size 可以在 的時間複雜度內完成,所以增加 tail
(指向 queue 中最後一個元素)以及 size
(紀錄目前 queue 有幾個元素)
q_new
q_free
q_insert_head
q_insert_tail
q_remove_head
q_size
q_reverse
q_sort
這邊是採用 MergeSort 的方式進行排序,q_sort
將 list 分成兩段,如果 list 大小是 2 的倍數則分成剛好 ,若不為 2 的倍數則左半將會切成 ,再將左右分別遞迴下去切直到遇到 Base Case ;接著執行 q_merge
將左右兩半排好
q_merge
less_than
比較 list_ele_t
的字典序
利用 make valgrind
來查看是否有 Memory leak …等記憶體錯誤發生,此階段並沒有發生什麼記憶體失誤
用 valfrind --tool=massif ./qtest
來執行 Massif 工具的分析
實驗的方式如下:
再利用 massif-visualizer [massif_output_file]
來把實驗結果輸出成以下圖表
可以看見一開始直線上升,應該是在執行 insert head ,後面一段雖在下降但是稍微平緩一點,應該是在執行 reverse 跟 sort ,之後開始較劇烈下降是在執行 rh 直到結束之後記憶體用量就將至0
(後續想再設計不同的方式去追蹤記憶體的使用)
Dude, is my code constant time?,解釋本程式的 “simulation” 模式是如何透過以實驗而非理論分析,達到驗證時間複雜度,需要解釋 Student’s t-distribution 及程式實作的原理;
解釋 select 系統呼叫在本程式的使用方式,並分析 console.c 的實作,說明其中運用 CS:APP RIO 套件 的原理和考量點。可對照參考 CS:APP 第 10 章重點提示