What's the difference between using XS and the Inline::C module? This was mentioned by someone in this question and has made me curious.
Inline::C generates XS and builds the generated module. It does this at run-time, although it caches past builds.
Inline::C is possibly easier to use, but there are a few downsides. The first time it runs, it slows down startup, it requires permissions to create files at run-time, and it requires the tools to compile the module. Furthermore, it makes it harder for a sysadmin to install.
The upside is that you can grab the generated XS and eliminate Inline::C once things start shaping up. This makes it useful for prototyping.
Inline compiles the C code at the same time when your Perl is compiled, and will be recompiled every time your source code is changed. XS is compiled once and the binary is saved as a .so file like a library.
Perl is written in C so XS uses the native Perl types and subroutine mechanisms. A module using XS runs almost as efficiently as a built-in language feature. It's more difficult to do some things in Inline, and there will be a conversion step when calling or returning from your code. That being said, Inline does a good job of not recompiling when not necessary, and the conversions into and out of Inline code aren't likely to be a noticeable performance hit.
Finally, writing XS assumes that you are packaging a module. There is a lot of setup and knowledge of Perl guts and module packaging required. If you just need to call a C library from Perl, you are better off using Inline.
© 2022 - 2024 — McMap. All rights reserved.