RUTHAN:
Nasledujici je muj pohled na vec, zcela jiste zatizeny (biased) (ne)zkusenostma s implementaci ruznych VM (a mnoha probdenyma nocema a vytrhanyma vlasama pri debugovani pro me nepochopitelnych bugu :-)
TL;DR: To se tezko zobecnuje. Zalezi na danem runtimu / VM a jeho designu. Rule of thumb je cim sofistikovanejsi runtime, tim mene se to vyplati (jinymi slovy, to co ti v (C)Pythonu pomuze, to se ti v Hospotu / J9 nevyplati). Jak rika KING, profiler je nejlepsi kamarad.
Long story:
C# neni ani lepsi, ani horsi nez ostatni. Moznost volat externi kod ma kazdy runtime/VM, (Java, vesmozne Smalltalky, LISPy, Python...), bez toho to totiz moc nejde. Java take mela od zacatku JNI. Uvaha ze
> C# to ma asi udelany dobre protoze tenhle unsafe C mod je tam od zacatku officialne
je, z meho pohledi, mimo.
Pri designu FFI jsi omezen designem runtimu / VM. Napriklad pokud VM pouziva svuj vlastni
stack pro managed kod, musis prepinat stack. Pokud pouziva jinou volaci konvenci, musis -ukladat registry (a toho nemusi byt malo, napr na POWER architekture ma 32 GPRs, 32 FPRs, 8 CCRs, 64 128bit VSRs...). Dalsi vec co musis resit je jak pristupovat k parametrum, co vsechno je treba udelat zalezi dost na designu memory manageru (moving / non-moving, write-barrier / read-barier / both). Java (JNI) je v tomhle extremni monstrum, protoze GC je implementation defined takze JNI musi pocitat se vsema variantama takze je indirekce na vsechno -> ma to svou rezii - a dost jinych jazyku je ale jeste horsi, protoze to neresi vubec takze se to programuje stytem "udelej to takhle, protoze tenhle runtime je primitivini a muzes si to dovolit" a pak to skonci na tom, ze nemuzes udelat nic lepsiho, protoze to rozbije veskery existujici kod. Hello, Ruby :-)
Ve zbylem prostoru v zasade vice ci mene vedome volis bod v intervalu