On Tue, Jun 26, 2012 at 8:48 PM, Stephen Chrzanowski <pontia...@gmail.com> wrote: > All; > > When you compile the amalgamation with your source code, doesn't the > compiler reject/not include/remove/doesn't consider the code that could > have been generated from the actual final build? In other words, if you > just have one function being used out of 10,000 functions, the final binary > would only include the code for that single function and not the 10,000?
Compilers definitely can't do that because they generate obj-files and if functions are not used in one obj-file they can be used in another one. Linkers probably could do that (although there are lots of limitations to that) but AFAIK they only optimize out the whole obj-files, not individual functions. That is unless you turn on Whole Program Optimization which as you understand is not turned on by default because usually it requires lots of computational resources. Pavel > OP; > > The big question is how much time you want to invest to meet your standards. > > Seeing that this is a Windows application, not something for a handheld > with limited resources, if the above is true, and you "pride" yourself on > making your binaries as small as possible, personally, I'd think the > 40-80-160 hours investment time to figure out how to get rid of the pure > "bloat" the DLL gives a plausible exercise into investigating this, even if > its on the side. > > On top of that, I'm the kind of developer who, if I have to require > assistance from an external source, I'll leave it external from my main > binary, that way if something does change, like FF in your case, then my > application just needs to update a single file, not the entire application. > > As much as I can appreciate that your program is under 400k (Which I remind > you is still smaller than the capacity of a 5 1/4 inch floppy disk, single > sided), no user on the planet is going to be concerned that your > application "blew up" to 900kb (Which now fits on a double sided 5 1/4 inch > floppy). I don't like bloat as much as the next guy, but when you're > talking applications the size of a meg, on what seems to be a windows > platform, NO ONE is going to notice a performance hit between a 400kb > application and a 900kb application. Not to mention bloatware, to me, is > more about how fast the system responds. If it takes more than 15 seconds > to show your initial UI, or you see elements of your UI just "showing up" > randomly, that would be bloat, even if its a 1 meg file. If your > application is in line with a "hello world" app, is gigabytes in size, but > everything seems to respond nice and quickly, excellent application, not > bloat, well worth the download/install time, as an end-user view. > > Bottom line, how important is [staying close to 400kb and removing external > dependencies] vs [having two physical files, in which, one can be updated > on the fly (Pending no application use)]? In your testing, if the new DLL > breaks, simply fix, and push out a new version. Otherwise, just have your > app download the DLL from you or the machine hosting SQLite. > > The other thing I just thought of, the fact that this library is available > AT ALL for better-than-free makes me jump for joy and hit my head on the > ceiling. Its a little black box that "works". That 500kb DLL is something > I didn't have to write, something that I can review and update if I want. > Its something I didn't have to invent, can easily plug into new > applications I write, small footprint, etc, etc. Personally, could be > 10meg in size, and I'd STILL use it. > > > On Tue, Jun 26, 2012 at 5:39 PM, E. Timothy Uy <t...@loqu8.com> wrote: > >> " 40-80 hours digging deep into how System.Data.SQLite.dll is built " >> >> Lol, I actually did this. >> >> On Tue, Jun 26, 2012 at 11:00 AM, Andrew Rondeau >> <andrew.rond...@gmail.com>wrote: >> >> > The answer of "just add sqlite.c to your project" is great when you're >> > making something in C. The entire world does not use C, nor is C (or >> > C++) always the best option for a particular project. >> > >> > Timothy Uy's offer actually makes a lot of sense if you're using >> > something other then C or C++. >> > >> > For example, I just can't ship a .Net .exe that uses x-copy >> > deployment, and runs on Linux/Mac (via Mono) unless I invest about >> > 40-80 hours digging deep into how System.Data.SQLite.dll is built. >> > >> > On Tue, Jun 26, 2012 at 9:10 AM, Simon Slavin <slav...@bigfraud.org> >> > wrote: >> > > >> > > On 26 Jun 2012, at 4:55pm, bi...@aol.com wrote: >> > > >> > >> Thank you everyone who took the time to comment on my Windows DLL >> > question. >> > >> I'm also glad I'm not the only one who sees the problem with not >> having >> > >> the version in the resource block. This really would have helped when >> > Chrome >> > >> and Firefox updated to a new version of SQLite and all my code stopped >> > >> working. >> > > >> > > This is the reason you will see so many posts here telling you to build >> > SQLite into your application instead of using a DLL. Then you are not >> > subject to the choices of any other person with code on your users' >> > computers. SQLite purposely issued a compact and simple amalgamation >> > version of the source code especially to make this fast and simple. >> > > >> > > Simon. >> > > _______________________________________________ >> > > sqlite-users mailing list >> > > sqlite-users@sqlite.org >> > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > _______________________________________________ >> > sqlite-users mailing list >> > sqlite-users@sqlite.org >> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
