還真的有Bug...
故事是這樣的...
我們公司寫的Silverlight應用程式在正式上線後,客戶用得很開心,對於這個技術和開發人員的努力頗有好評,正當我們被客戶讚的輕飄飄,準備明天跟客戶端的老大demo的時候,前線傳來一個令人錯愕的消息...
用我們寫應用程式的電腦會當...在客戶端3台不同的電腦測試,就像機器得了機瘟一樣,早上還OK,突然間下午全當了,只要進入某一個畫面之後, IE就當給你看,Chrome也死給你看,FireFox就懶得測了。
Demo在即,碰到這種事情,非出面不可了...詭異的是,在家裡連到客戶端的網站,一切OK,我們公司沒有一台機器有問題,都算是很順,只好去客戶那邊看看。到了客戶端,正如客戶所說,沒有一台電腦能夠正常執行,而且客戶強調,早上還OK,就到下午,全不能動了...>_<
這...也太誇張了吧。
測試結果正如客戶所說,很清楚明顯的Run Silverlight的瀏覽器就是卡在那邊不動。
那...到底在run什麼呢? 看不太出來,因為我們知道程式碼只是call一個WCF Services,並且把一堆字串傳到用戶端。當然,我們懷疑過字串的大小,但經過測試,其實才幾十k,比圖片小多了。況且早上都還OK,怎麼下午就不能動了,碰到網路傳輸瓶頸也不會這樣才對。
更詭異的是,如果有資料傳輸的瓶頸,那為何在我們公司OK呢?
CPU / RAM / GPU / intranet performance 都測過之後,突然間想到,似乎客戶端所有的PC都是XP,而我們公司所有的PC都是Win7...
果然,在客戶端換了Win7之後,一切正常,回公司換了XP之後,IE當掉。同樣的一段code,怎麼會這樣呢?到底是什麼code有這麼大的魔力...答案如下:
那為何會讓XP當掉呢?又為何Win7沒事呢...答案是...我也不知道...不過好在我不是第一個碰到這個問題的人...請參考底下...
http://connect.microsoft.com/VisualStudio/feedback/details/615069/silverlight-4-code-using-indexof-startswith-endswith-default-overloads-very-slow-for-xp-browsers
https://connect.microsoft.com/VisualStudio/feedback/details/629358/performance-problem-string-indexof-and-string-startswith
今天碰到這個問題,我們還沒有時間去找微軟是否已經提出了解決方案(或是SL5才會修正),但先列出來提供開發人員參考,也作為紀念,而我們的AP當然先workaround了,畢竟本來的寫法也不是個很有效率的做法,倒是Silverlight會有這個問題頗讓人訝異的。
分享
我們公司寫的Silverlight應用程式在正式上線後,客戶用得很開心,對於這個技術和開發人員的努力頗有好評,正當我們被客戶讚的輕飄飄,準備明天跟客戶端的老大demo的時候,前線傳來一個令人錯愕的消息...
用我們寫應用程式的電腦會當...在客戶端3台不同的電腦測試,就像機器得了機瘟一樣,早上還OK,突然間下午全當了,只要進入某一個畫面之後, IE就當給你看,Chrome也死給你看,FireFox就懶得測了。
Demo在即,碰到這種事情,非出面不可了...詭異的是,在家裡連到客戶端的網站,一切OK,我們公司沒有一台機器有問題,都算是很順,只好去客戶那邊看看。到了客戶端,正如客戶所說,沒有一台電腦能夠正常執行,而且客戶強調,早上還OK,就到下午,全不能動了...>_<
這...也太誇張了吧。
測試結果正如客戶所說,很清楚明顯的Run Silverlight的瀏覽器就是卡在那邊不動。
那...到底在run什麼呢? 看不太出來,因為我們知道程式碼只是call一個WCF Services,並且把一堆字串傳到用戶端。當然,我們懷疑過字串的大小,但經過測試,其實才幾十k,比圖片小多了。況且早上都還OK,怎麼下午就不能動了,碰到網路傳輸瓶頸也不會這樣才對。
更詭異的是,如果有資料傳輸的瓶頸,那為何在我們公司OK呢?
CPU / RAM / GPU / intranet performance 都測過之後,突然間想到,似乎客戶端所有的PC都是XP,而我們公司所有的PC都是Win7...
果然,在客戶端換了Win7之後,一切正常,回公司換了XP之後,IE當掉。同樣的一段code,怎麼會這樣呢?到底是什麼code有這麼大的魔力...答案如下:
if(arg.Result.IndexOf("Info")==0) return;arg.Result是一個string, 如果有經驗的Silverlight developer應該猜的到,這是WCF Services的回傳值,很單純,內容就是字串。
那為何會讓XP當掉呢?又為何Win7沒事呢...答案是...我也不知道...不過好在我不是第一個碰到這個問題的人...請參考底下...
http://connect.microsoft.com/VisualStudio/feedback/details/615069/silverlight-4-code-using-indexof-startswith-endswith-default-overloads-very-slow-for-xp-browsers
https://connect.microsoft.com/VisualStudio/feedback/details/629358/performance-problem-string-indexof-and-string-startswith
今天碰到這個問題,我們還沒有時間去找微軟是否已經提出了解決方案(或是SL5才會修正),但先列出來提供開發人員參考,也作為紀念,而我們的AP當然先workaround了,畢竟本來的寫法也不是個很有效率的做法,倒是Silverlight會有這個問題頗讓人訝異的。
分享
留言
我漏提了一個狀況,因為這個問題確實也和資料量有些關係,在資料小於50k以前,客戶端曾感覺較慢,但從來沒有導致IE當掉,因此也從來沒反應過這個問題...(因此就被客戶端的MIS解讀成一切都OK了...)
問題爆出來,是因為IE直接當了, 問題才被反應給客戶端的MIS, 才到我們家...從這邊也發現,其實end-user不一定會把每一個問題都立即反映出來,且end-user的描述有時候和實際狀況也並非100%相同...