我們有很多舊的Perl腳本連接到MS SQL數據庫處理一些記錄，並生成文件。隨着時間的推移，日常交易規模不斷增長，這些腳本變得越來越昂貴。編寫C＃（.NET）或PERL文件更快嗎？
此外，數據庫隨着越來越多的表增長，修改舊的Perl腳本非常麻煩。正在考慮重做.NET下的一些主要腳本（使用C＃）
運行Windows Server的計算機使用一個vs另一個時，是否有速度優勢？
同樣的想法是
執行查詢
處理結果通過了一些基本格式
結果寫入文件
取決於多麼愚蠢的各自的程序員都是。當正確初始化時，他們都應該舒適地飽和帶寬系統的任何帶寬 - 而且這是你的瓶頸。進行大量緩存寫入（.NET BufferedStream），並讓您擁有SSD或快速準備好的東西。正確編程的perforamcne瓶頸是這類工作的光盤子系統。
在寫入性能方面，我不認爲這些語言有很大差異（通常瓶頸將是硬盤，而不是CPU的處理能力）。你應該看看「維護代碼的代價」，在C＃中你可以得到更清晰的代碼，更不用說與MS SQL的集成可能會更有效率，更不用說你可以使用線程了。
更好的代碼，更易於維護，可能更快。是的，C＃是個好主意
你也可以在Perl中編寫更乾淨的代碼，這取決於程序員而不是語言。 –
這兩種任務都可以用兩種語言同樣快速地完成。他們也可以在兩種語言中都犯了可怕的錯誤和可怕的速度，所以有這樣的考慮。
從你的另一個意見中，你提到你在SQL服務器端進行格式化。如果你在應用程序端做了這些查詢，這些查詢可能會便宜很多，然後將此腳本移到更快的機器上，以至少影響數據庫服務器。
我猜硬盤速度是你現在最大的問題。你應該在運行這個腳本時監視資源 - 它是否讓你的cpu最大化？它對內存的讀/寫有多大？（它不應該）。它大部分時間只是在磁盤I/O上等待？如果是這樣，你應該考慮將存儲升級到更快的磁盤，RAID或SSD，具體取決於你的情況。
即使只是像磁盤碎片整理這樣的東西可能會有所幫助。
如果你有足夠的cpu /內存來備用，但是不能避免慢速磁盤，你甚至可以在寫入內容之前先考慮壓縮內存中的所有輸出（再次，假設這是一個好主意，它取決於哪裏這些報告正在進行，需要什麼格式）。
根據「基本格式」的複雜程度，SSIS可能更適合您的問題。 –
無論如何，99％的格式化都是在查詢級完成的。 Perl主要抓取查詢，做一些日期檢查等。從命中的角度來看，99.9999％的成本是實際寫入文件的數量， – Sam
您的問題可能與實際語言涉及的磁盤速度有關。運行一些性能統計信息並查看腳本是否從I/O角度飽和服務器可能會有所幫助。您的解決方案可能是SSD而不是C＃。 – kdmurray