鏡子裡面的像為什麼左右是反的而上下不是？
我問過很多朋友這個問題很少有人能夠在３分鐘內給出准確答案這裡列舉出一些比較奇特的想法
因為人的眼睛是左右對稱的（也是某面試寶典中的答案）
如果把鏡子橫過來左右不反了上下卻反了
因為我們在北半球
從技術層面上說這裡涉及的知識點只有鏡面反射遠比Windows內存管理簡單但是要回答清楚卻不是信手拈來那麼簡單這個例子只是想說明除了知識以外解決問題需要清晰的思路
絕望的性能問題ADONET竟然比要慢
問題描述
根據下面一篇文章的介紹客戶決定升級到NET Framework 來借助ADONET 提高性能
DataSet and DataTable in ADONET
但是根據用戶的測試使用ADONET 後性能反而下降
拿到用戶的代碼一看非常簡單
OracleConnection conn = new OracleConnection();
connConnectionString = ;
connOpen();
OracleCommand cmd = new OracleCommand();
cmdConnection = conn;
OracleDataAdapter dap = new OracleDataAdapter(select * from mytesttableconn);
DataTable dt = new DataTable();
DateTime start = SystemDateTimeNow;
dapFill(dt);
TimeSpan span = DateTimeNow start;
connClose();
ConsoleWriteLine(spanToString());
ConsoleWriteLine(The ColumnsCount is + dtColumnsCountToString());
ConsoleWriteLine(The RowsCount is+dtRowsCountToString());
測試用的數據庫表也很簡單萬行數據個字段通過檢查spanToString的結果發現同樣的代碼ADONET 比多用了近一倍的時間dapFill方法的執行時間從原來的秒增加到秒
悲觀和絕望
應該如何著手解決這個問題？
我測試完成看到這個結果後我的感覺悲觀看看我們能夠做什麼
後台數據庫表格的定義非常簡單個字段都是int都是在沒有indexprimary keyforeign key等約束條件下測試的也就是說這個問題跟數據表的Schema定義無關完全是客戶端的問題
代碼已經非常簡單Console工程裡Main函數就做這麼一件事情客戶端沒有任何可以修改和變動的地方
NET Framework 和NET Framework 共存在同一個客戶端測試也是在同一個客戶端進行的所以軟硬件環境比如Oracle Client都相同唯一的區別就是NET Framework的版本這也就是客戶最關心的地方
這個工具可以顯示出每一個方法（包括子方法）調用所花費的時間以及占整體運行時間的比例為了讓問題更加明顯這裡把數據庫的行數增加了萬來方便觀察沿著花費時間比例最多的函數一路走下去發現DataReaderRead的方法實現分成兩部分自身的托管代碼調用和非托管代碼調用分別占用了%左右的時間和%左右的時間有了這個信息後再通過Reflector分析ADONET中的對應函數的實現（VS自帶的Profiler無法分析NET Framework 的程序不然直接分析兩者時間比例就可以方便地看出問題）發現非托管代碼部分的調用幾乎沒什麼差別都是調入數據庫的客戶端非托管DLL主要差別在托管代碼部分其中引起注意的是ADONET 增加了SafeHandleDangerous AddRef/DangerousRelease調用每一對這樣的調用就要花費%的時間而每讀取一行數據需要用大約對這樣的調用經過比較分析認為問題就是在這裡
由於對數據庫的操作和數據填充最終通過調用非托管的數據庫引擎來完成所以需要向非托管的DLL傳入托管代碼管理的緩存空間而SafeHandle就是管理這種資源的在NET Framework 中由於缺少SafeHandle類高負載環境下程序存在表現不穩定的危險沒有完美的解決方法NET Framework 增加了SafeHandle來保證程序的可靠性然而代價就是萬行數據發生秒鐘的時間損失（後來經開發人員確認這秒鐘的損失在下一版本的Framework也可以想辦法優化掉！）
結論和收獲
在跟客戶作進一步的交流後這個問題的結論如下
MSDN文章的介紹是正確的如果用文章裡面的例子的確可以看到性能有數量級上的提升
在客戶的真實環境中損失的秒時間其實不會對最終用戶和整個程序造成影響
秒鐘不是白白損失的換來的是程序的可靠性
From:http://tw.wingwit.com/Article/program/ASP/201311/21683.html
