之前有看到幾篇文章說
直接接線與用Local variable去比較,發現說直接接線所耗記憶體會比較低
那如果接線的長度是很長,有兩個螢幕畫面以上的那種長度,這樣用Local variable會不會有較好呢?
而在處理速度上,一般來說應該是直接連比較快
那如果是上述的長度問題,用Local variable會不會比直接接線來的快呢?
感恩!
基本上軟體的線跟實際的線不一樣…
所以即便他有很多個銀幕那麼長，它的含義都是"資料傳遞"
但是有時為了程式撰寫方便，便會建立區域變數，與線直連不同，本身他就多了一個儲存變數的行為
故撰寫程式，當考量到該輸出可能會用於許多計算、輸出本身會被疊代計算、輸出本身為控制項，用於許多觸發或判斷時，
皆可將該輸出採用區域變數的方式，除了簡化接線使得程式維護容易之外，也可運用於並列或是判斷的執行上。
跟線的長度無關。所以就算連接的線相當長，其實還是比local variable省記憶體。
caeru大大寫的很詳細
感謝大大們的回覆
那在速度上來說呢@@?
兩者會有很大的差別嗎??
單純比較"直接接線傳遞資料"以及"利用變數傳遞資料"
以我的電腦處理結果如下(因每個人電腦處理速度不同而有所差異)：
直接傳遞資料一千萬次耗時2899ms
利用變數傳遞資料一千萬次耗時4352ms
代表在我的電腦上每傳遞一次資料，兩者相差0.15us以下，
用另一個方向來思考：
1. 該程式是否需要高速運作？
>>不需要→不需要考慮這兩者資料傳遞方式之差異，單純就程式撰寫之架構及便利性來評估即可
>>需要→考量下一點
2. 程式高速運作時，需要要求其時間準確度為何？
>>大於1ms→不需要考慮兩者之差異(誤差於萬分之二以下)
>>小於1ms→考量下一點
3. 程式於高速運作時，對於資料取得、計算之時間有相當要求，該如何處理？
>>預先規劃好資料矩陣大小(記憶體規畫問題)
>>善用REPLEASE ARRAY / AUTO INDEX ARRAY來取代BUILD ARRAY(記憶體規畫問題)
>>簡化不必要的變數(ex.上述提到的問題，可以直接連線VS考量程式架構需要用到變數)
>>簡化不必要的計算次數(ex.同樣是找質數的計算，每種方式寫出來都不一樣，因為迴圈使用次數不同)
有時候簡單的程式不需要考量太多導致寫出奇怪(?)的程式，就如同要用什麼刀就看是要宰什麼樣的對象一樣: )
以上是簡單的思路，提供參考
caeru41190.5077546296
所以local variable & glable variable 都不符合資料流形態
請教一個問題 queue 為什麼反而不會這麼耗時間?
turaki41190.5346296296
[QUOTE=turaki]
所以local variable & glable variable 都不符合資料流形態
請教一個問題 queue 為什麼反而不會這麼耗時間?
[/QUOTE]
以相同方式進行測試queue存取時間，
執行一千萬次所耗的時間為9544ms，
遠大於前兩種方式。
不知前述之"queue 為什麼反而不會這麼耗時間"是基於何種測試條件?
queue之所以比較耗時間，在於上述兩種資料的大小是固定的，
但是使用queue時電腦需額外進行動態記憶體配置(印象中是如此)，
所以用在這方面的效能是比較低的。
queue主要功能並非看重於其資料傳遞的效能，
而是當作state machine的窗口作先進先出/先進後出的行為之用，
簡單說就是一個等待菜單的中央廚房窗口，或是待機中的伺服印表機。
常應用的範疇為state machine的設置、Producer/consumer，這常見於一般工廠產品測試步序的設計上。
謝謝大大!我理解了!
不管用什麼變數都比直接拉線耗時間!
我猜想大大剛剛所說的queue 不會那麼號時間原因
可能就像是大大所說的!把生產與製照分開!cpu 就不會這麼吃重!
效能也就相對提高!
我觀念很模糊!謝謝大大提醒!
所謂提高效能!就是不要做重複的事情!再做一遍!
就像是大大所說的!直接拉線!那程式就不用再產生記憶體讓我們放入變數!
直要程式再次提供給我記憶體!就會消耗我們的效能與時間!
而queue
卻是把偵測與動作分開!所以才如大大所說的!他並非專攻傳輸資料!而是等待資料予以動作!
謝謝
原來如此,感恩大大們的指導~