看板
[ Ruby ]
討論串Ruby on Rails 的速度議題
共 19 篇文章
內容預覽:
出自我的Blog. http://lightyror.blogspot.com/2006/10/ruby-on-rails.html. 剛剛看了 JavaEye 裡面的 從JavaEye2.0網站看ruby on rails性能討論串,裡面 Robbin 有提到. 單純比較JVM,PHP解析器,ru
(還有2170個字)
內容預覽:
先說,我壓根沒用過回血戒,也不知道怎麼用 C 寫 CGI. 更重要的是,我不是打著捧 Java solution 反 Ruby solution 來回這篇. 只是覺得其中幾個議題很怪異. 根據上面這段很多問號的文章. 基本上,Ruby 處理比較漫,這是公認的(至少,不是我說得 XDXD). 我對 T
(還有1259個字)
內容預覽:
[束刪]沒問題,我還有一個更更更怪異的論點,只是還沒談而已問號很多是因為那是簡體字BBS先天的缺陷 XD沒錯 XD是的,不過考慮那些東西已經太複雜了. 所以一切的數據比例,我以 " 經驗 " 來推測. 本來就是相當見仁見智的東西你不覺得@@!,那我也沒辦法說有啥問題. 單純以我這個頁面來說(就我這個
(還有1860個字)
內容預覽:
原文我就全刪除了.... 直接挑著講比較白刀子進紅刀子出一點 \囧/. 基本上,我們都同意. a. 如果在小型網站、需要快速回應需求變更. 那麼開發效率的確比語言的處理速度還要重要的多. b. 如果提供較佳的環境(較充裕的 resource). 那麼語言處理的速度,差異量就較小. c. 運算部份的主
(還有1591個字)
內容預覽:
恩,第一個我沒有辦法做出這個時間比例. 因為我根本沒有相關的資源去作推(懶得作也是實情啦). 所以我只好信任我的經驗. 你要問我有沒有根據. 我只能跟你講沒有作過所謂的精確的實驗. 說實在話,我已經預設使用 Rails 是來開發網站. 所以,我直接預設以開發網站來當作這個論點的環境. 今天這個論點會
(還有595個字)