2009-05-27 126 views
3

我目前使用QtScript作爲我的C++應用程序中的腳本功能,但它在cpu上相當「沉重」。當線程評估循環中的所有腳本時,CPU使用率會增加到90%-100%。即使我把它每5個腳本睡1毫秒,CPU使用率仍高於75%。輕量級C++腳本庫

是否還有其他易於實現的腳本框架比QScript輕得多?

編輯:

我現在認識到這是正常的行爲,而不是在QtScript一些拱錯誤。聽聽什麼樣的(輕量級)腳本庫可用仍然很有趣。

+2

你確定你沒有做一些愚蠢的事嗎?你有沒有嘗試過一個簡單的腳本作爲測試。 – 2009-05-27 14:51:28

+0

@mgb:即使你不明白到底發生了什麼,也要記住看看你的中間表示(字節碼,反彙編,解析樹,無論什麼),但有些問題可能會非常明顯! Alloc/dealloc列表或其他內存使用統計信息也可以提供幫助。 (任何有QScript經驗的人都會在意與其他信息的聯繫嗎?) – leander 2009-05-27 16:46:57

回答

16

看看Lua,它經常在遊戲中使用,所以表現一定很好。

+0

啊,是啊,我之前聽說過Lua。我明天會進行一些測試。 – 2009-05-27 14:05:46

+0

不會執行不阻止使用100%CPU的Lua腳本嗎?我希望如此,否則我會認爲它壞了。 – KeyserSoze 2009-05-27 20:03:33

3

Lua很好,因爲它使用棧來解釋器和C++之間進行通信。這很好,因爲它不涉及任何可見的引用計數,從而簡化了事情。

這是一個有趣的比較作爲一些iolanguage的背景:iolanguage

12

那麼,你期望什麼?除非腳本必須等待磁盤或用戶I/O,否則CPU 應該以100%運行。

是你的問題,它運行時間很長?

或者說你的應用程序沒有響應?

在這種情況下,問題在於您的腳本阻塞了所有UI交互運行的線程。一般的解決方案是阻止所有UI輸入(除了「取消腳本」按鈕:)),並將實際處理移至單獨的線程。

[編輯]
稍有不同的問題:在100%的CPU雖然沒有腳本來處理?

如果你正在處理的東西,100%的CPU是好的,健康的。

CPU總是處於繁忙狀態,當前線程總是會佔用正在運行的核心的100%。 「0%CPU活動」實際上意味着所有的週期都花在系統空閒線程中(屬於你在任務管理器中看到的「系統空閒進程」)。作爲一個簡單的示例:如果您有一個應用程序線程處於活動狀態,並且CPU使用率爲40%,並且您的任務管理器更新時間間隔爲1秒,則應用程序上會花費400毫秒的CPU時間,而空閒線程上的時間爲600毫秒。

2

我聽說過有關TinyScheme的好消息。據說,我們在這裏使用Lua(在遊戲開發工作室,針對嵌入式和手持式系統)。

需要注意的事項,雖然 - 和Lua具體,但我認爲這些適用於許多這些語言:

  • 定製輕便的小對象分配器可以得到很多的表現;許多這些lanugages是分配沉重。使用池或基於幀的分配器可能值得您一段時間,這取決於您可以擺脫什麼。
  • 根據使用的GC策略(因爲大多數這些語言都是垃圾回收),您需要保持GC掃描區域較小 - 例如,整體小盧亞堆大小。花一些時間重新組織數據以將其置於GC域之外(例如,保留C++端,以某種方式標記它,以便GC知道避免它等)可以提供幫助。
  • 同樣,增量垃圾收集可以是一個很大的勝利。我建議嘗試 - 在某些情況下(小堆),我發現GC的速度比增量快。
2

我個人會推薦Lua在我們的嵌入式平臺上廣泛使用它。如果你正在windows上運行,你可能會使用類似LuaJIT的東西來使你的Lua更快更快

但是,由於沒有人提到過它,所以你可能還想看看Squirrel(http://squirrel-lang.org/)。我沒有任何經驗,但我認爲它看起來很有希望。

至於你當前的問題,如果沒有任何東西會阻止它,任何代碼都會佔用100%的CPU。

類似的信息(僞代碼):

爲(I = 1,10000000000000) N = N + I 端

,直到它在(幾乎)任何語言完成

將採取100%的CPU因爲沒有什麼可以阻止它執行。

1

這真的取決於幾個因素:

  • 威爾腳本中使用了大量的應用程序?
  • 腳本是否會變得複雜?
  • 您是否將很多功能暴露給腳本引擎?
  • 你是否在意Qt的良好整合?

我也推薦Lua,但是,你應該記住下面的內容:Lua在純ANSI C中實現。這使得它超便攜,但是如果你在C++環境中開發,它會導致到很多「包裝」類。特別是當你想暴露Qt功能(所有它是SIGNAL s,SLOT s和PROPERTY s)時,它會導致很多重複的代碼。

0

你也可以嵌入JavaScript與spidermonkey 我認爲JavaScript比盧阿更廣泛。

0

從目前爲止我所知道的QtScript沒有什麼問題(只是從4.6開始使用它,所以對它仍然是新的,但到目前爲止還是喜歡它)。取決於你如何使用它,就像lua或python一樣。如果你保持原生的應用程序核心功能(從c/C++編譯),並且只向腳本引擎提供一個最小的API,那麼一般來說,你可以讓事情保持快速。

使用QtScript,以合理的線程安全方式(QT的插槽和信號對象模型)公開對象及其方法並輕鬆地將腳本創建的對象傳遞給本機函數是相對容易的......但您可能會緊緊地與QT環境整合(這可能正是你想要的)。

如果你想任意地將本地C++對象暴露給其他嵌入式腳本環境結帳SWIG。 SWIG與toLua工具類似,但適用於許多可嵌入語言,如lua,c#,tcl,javapython等等。從經驗到Luua制定綁定對象和方法到腳本是一個非常痛苦的過程,而且我也沒有聽到有關SWIG的許多壞事。