是否可以「內聯」一個「方法」？

我對inlining declamations做了一些粗略的閱讀，並在relevant CLHS pages上閱讀，但不能輕易看到明確的答案。是否可以「內聯」一個「方法」？

當foo使用defmethod而不是defun（後者明確是一個覆蓋的情況）聲明(declaim (inline foo))是否合理？如果foo是class的reader函數？這種內聯的效果在性能方面是否顯着？它是否以某種方式特定於實現？

對於在嚴格限制條件下的簡單方法，可能有必要重新編寫defun以實現特定性能，但這有時是困難的或不可能的。有沒有一種通用的優化策略可以使Common Lisp方法在不重寫函數的情況下運行？

來源

2016-12-13 Inaimathi

請參閱https://github.com/guicho271828/inlined-generic-function – coredump

@coredump - 據此，看起來情況是「內聯泛型函數/方法通常會導致可忽略的性能增益，並且可以得到改進在優化的情況下，代價是使用外部庫，額外的元類聲明以及未優化情況下的性能較差「。它可以從'quicklisp'作爲'內聯泛函函數'使用，所以探索是很經濟的。你知道它是否也觸及'reader' /'accessor'的情況嗎？並且，想要將其作爲答案發布？ – Inaimathi

請注意，Common Lisp程序不會調用單個方法，而是調用通用函數。 –

內聯方法沒什麼意義，因爲CL編譯器在事先確定要調用哪個函數時可以做到這一點。如果有明確呼叫(foo x)而foo被內聯，則可以替換foo的定義。但是，當正在編譯的代碼是(funcall method x y)時，如果method未知，則無法內聯函數。

這就是通用函數所做的。事實上，你不會自己調用方法，你讓對象系統決定應該調用哪些方法。 CLOS允許你添加和刪除方法，所以你不得不忍受系統是動態的並且有一些運行時成本的事實（有些實現可以封裝泛型函數，顯然是爲了防止進一步的變化）。但是，它在實踐中非常有用，並節省了大量的開發時間。我還沒有找到一個動態調度花費太多的情況，但我沒有大量方法的經驗。

您可以查看Robert Strandh的論文Fast generic dispatch for Common Lisp，以獲取關於更快地進行通用分派的想法。還有一個庫提供Inlined Generic Functions，其中明顯的泛型函數可以在適當的情況下在編譯時高效地分發。

來源

2016-12-14 19:55:36 coredump

是否可以「內聯」一個「方法」？

回答

相關問題