Re^4: modularization, memory usage and performance

[jmagiera]

It's a good idea, and probably faster than Tie::Persistent. However, the package needs to compile some libs, and I want my application to be used by normal Windows-Users also (who don't have a compiler installed). Is there a way I can pre-compile it and let the end-user skip the compilation part when installing it? Hm.., the ppm of ActivePerl does that. Maybe I should use that for Windows-Users.

[jplindstrom]

You want either PAR, PerlApp or perl2exe, which can package your Perl program into a self-contained .exe file.

Then you can safely go with DBD::SQLite.

/J

[jmagiera]

Thanks for the idea, but I definitely do not want that. That will make updating a pain in the butt for the users, because they always need to get the full exe. I'd like to keep things slick and small. I have an auto-update feature in my appilcation and right now, a simple bugfix is usually less than 100K download for the users.
Also, I don't want to create platform-specific distributions (that's what perl is for, right?).

[jplindstrom]

Well, a simple installation often has little to do with the size of the upgrade. I don't know your situation, but if it's within a company LAN, the size of the download is irrelevant. From your post I guess it involves a download over the Internet, so it may or may not be important to the users.

But trust me on this: if you want your users to have an uncomplicated installation process, the single best thing you can do is to make it one file they need to deal with. No directory structure, no requirement to have Perl installed, and most importantly, no module dependencies to deal with. This is especially true if your users aren't particularly geeky.

PAR works for both Unix and Windows, and it's possible to package many platforms in a single binary (but that will obvioysly increase the size).

/J