BricsCADのLISP
BricsCAD の LISP API は、AutoCAD の AutoLISP互換を維持しつつ、更に発展された API となっている。
BricsCAD で実装されている関数の概要
- AutoLISP ： AutoCAD 互換の関数。細かな仕様の差もほとんどない。
- VLE-関数 ： VLA関数はWindowsでしか使えないけど、それと対応する VLE関数はLINUXやMACでも使えるように実装されている。
- シートセット関数-BricsCAD：シートセット機能をコントロールするための関数群。AutoCADは他のAPIを使わせたいのか一向に実装されないが、BricsCAD では扱える。
- tin+civil関数-BricsCAD ： BricsCAD PROにある土木機能と合わせて実装されている関数群。Tinサーフェスを作成・編集したりできる。AutoCAD Civil3Dの読み込み関数なんかもある。
- bim関数-BricsCAD ： BricsCAD BIM の製品用に実装されている関数群。BIM系のオブジェクトや定義を作成・編集したりできる。
- シートメタル関数-BricsCAD：BricsCAD Mechanical の製品用に実装されている関数群。板金オブジェクトや定義を作成・編集したりできる。
Fast-COM
BricsCAD が Linux に移植された際、Linux には COM がないため、COMベースのLISP関数（vla、vlax、vlr関数セット）をLinux（後のMacも同様）でも提供する問題に直面した際に実装され始めた仕組み。 BricsCAD Linux/Mac用の vla, vlax, vlr機能セットを提供することが主目的なしくみだが、Windowsでも有効的に作用し、標準の Windows COM に比べて、通常50%、最大1000%（10倍）以上の著しい性能向上と、Windows および Lispエンジンメモリの両方の負荷軽減が提供される。 Lisp のメモリ負荷が軽減されると、ガベージコレクションが減少するため、この点でも間接的に性能向上が得られる。
Microsoft COM TypeLibraries (.tlb と .idl ファイル)と非常によく似た形で実装されていているので次のように使える。
- プロパティ関数は、専用関数（vla-get-<property> ...）または汎用関数（vlax-get-property '<property> ...）両方に対応している。
- メソッド関数についても、専用の関数として呼び出し（vla-<method> ...）、汎用的な呼び出し（vlax-invoke-method '<method> ...）両方に対応している。
実装の背景
- Windows COM のデータラッピングやマーシャリングは、パフォーマンスやメモリ消費に大きな影響を与えるため、これを回避する。
- ターゲット関数と引数が TypeLibrary の記述と照合されるため、比較的遅い Windows COM 関数呼び出しメカニズム (::DispInvoke(), IDispatch::Invoke() など) をバイパスする。
- データ型のラッピング/マーシャリングと動的なCOM関数呼び出しの解決は前方および後方で処理される。
- Lispエンジンは、COMオブジェクト記述の効果的なキャッシュを使用し、Teigha（TX）およびBricsCAD（内部）のインターフェイスとC/C++レベルで直接動作するため、ARX/BRXコードに非常に近いパフォーマンス（約80%〜90%）を実現している。
BricsCADの各バージョンで、より多くのプロパティとメソッドがこのモードをサポートし、BricsCAD Linuxでも同様に利用できるようになる。
Fast-COM 実装は、vle-fastcom関数によって実行時に有効/無効を切り替えることができる。
; Colorプロパティ値は通常のWindows COMアクセスで取得し、Layerプロパティは "Fast-COM "モードを使用してアクセスする例。 (if vle-fastcom (vle-fastcom nil)) (setq res (vla-get-color <object>)) (if vle-fastcom (vle-fastcom t)) (setq res (vla-get-layer <object>))
統合LISPオプティマイザの仕組み
AutoCAD の AutoLISP は、80年代半ばに開発された古い XLisp方言をベースにしているため、最近のLisp方言では標準となっている基本的なLispコア機能が大幅に欠落している。そのため、AutoLISP を用いたアプリケーションは、AutoLISP の制限された組み込み機能を用いて、この基本機能の多くを独自に実装しなければならない。(うちのGzLibもある意味これを緩和するために作ってる。)
これが原因で、AutoLISP アプリケーションのコードには非効率的なコードパターンが含まれることが多く、メモリと性能を浪費することになる。単に、よく使われる多くの機能を実装するのに他に方法がないため。
BricsCAD の Lispエンジンは、最新の OpenLispコアエンジンを使用しており、優れたパフォーマンスと最新の Lisp言語機能をフルに備えているもののすが、OpenLispコアのパワーは AutoLISP の互換性を保つために隠され使用されていない。
このような「対立」に直面し、多くのコア機能、快適性、性能（さらには他のAutoLISP互換システムとの互換性）を提供する VLE関数ライブラリのアイデアが生まれた。 ただ、Lisp の開発者が VLEのライブラリを使ってアプリケーションを調整する心理的・時間的な敷居が高いという状況があるため、これに対する別のアイデアとして、自動Lispコード最適化ツール（統合LISPオプティマイザ）が爆誕した。
統合LISPオプティマイザは、Lispコードをロード時に解析して非効率なコードパターンを検出し、より効率的なコードパターンに置き換えるもので、完全に透過的で開発者側の努力は不要になっている。
（要は勝手に高効率なコードに最適化してくれる。AutoCAD のコンパイル時に行われる最低化とは別のアプローチ。）
「Lisp Optimiser は、今後の BricsCAD のバージョンアップにより、より多くのコードパターンに拡張される予定」とアナウンスされているので、LISP で書いとけば勝手に効率化されるケースが増えていくことが期待できる。