Great discussion, if somewhat amusing (with a hint of deja vu) for an old hack like myself.
I remember discussions like this back in CP/M days when it was a move rom 8 to 16bit. Oh, and it all happened again when 32bit came along and yes now we are into 64bit and it carries on. Simple really, the OP is completely correct to be requesting a 64bit CLI as we are now very much in that world. Of course a legacy 32bit version is appropriate but surely the mainstream dev must move on to 64bit at some stage? Not for me to say when this should occur but surely it is inevitable or am I just an old dinosaur? Some excellent side points made (single out DD here) and one o the standouts is the quite ridiculous stance many developers take regarding user requests such as the one made in the OP. There is absolutely no requirement at all for end users to be software developers/engineers, that would be absurd and I doubt this was ever the intent of sqlite development. Roll your own compilations in some cases are not an option and quite possibly for multiple reasons. I'm not going to bore you by expanding the obvious, but the OP identified one such case as a regulated corporate environment, a beast I am unfortunately all too familiar with. Ryan is very right about the relative ease of such exercises but IMHO wrong that it suits all, or even most cases. I may be old, but I'm a progressive dinosaur. We have to move on, and in this biz, quickly if we want to remain in any way current. We can make choices as developers about whether we embrace such things as OO or R or whatever new methodology comes along but we don't get that same choice about base system changes such as 16/32/64 bit processors. They are like death and taxes, inevitable. So when the 64bit CLI arrives, as it surely will do, the OP will be vindicated and all the rest will be historic fluff. Just my opinion, but as I said great discussion from my very favourite technical list. On 11 August 2016 at 01:11, Jim Callahan <jim.callahan.orla...@gmail.com> wrote: > The issue is not simply recompiling the CLI for 64-bit; I assume you want > the tested reliability of SQLite. > > "The [SQLite] project has 787 times as much test code and test scripts" as > it does source code for the executable. > https://www.sqlite.org/testing.html > > > Running the exact same tests would not be enough, because you (and I) would > want special tests for larger than 4 GB > RAM. So, additional tests would have to be developed. > > So, I see three alternate solutions: > > 1. Find a corporate sponsor to fund development of 64-bit SQLite CLI > > 2. Remove some tables from memory (though it sounds like your difficulties > are caused > by recursion rather than the size of the raw data) > > 3. Use SQLite for persistent storage but move the in memory (tree > navigation) operations to another (open source) language > such as C, Java, Python or R (or the new Julia language that is approaching > version 1.0) that has interfaces for SQLite > and a 64-bit build for Windows. You will probably need another language to > display the output anyway why not take > advantage of Python, R or Julia? > > Even if you move to another language, you may find that your problem is > recursion. > In my experience, computer science textbooks give elegant examples using > recursion, > but then say the solution is not scale-able and give a less elegant > solution using iterative techniques. > > Jim Callahan > Data Scientist > Orlando, FL > > > On Tue, Aug 9, 2016 at 10:31 AM, Rousselot, Richard A < > richard.a.rousse...@centurylink.com> wrote: > > > I would like to request a SQLite official 64-bit SQLite3.exe CLI (not > DLL) > > be created. > > > > I have reviewed the prior discussions regarding 64-bit SQLite3 and the > > reasoning for which why creating a 64-bit version is denied are "it does > > not make a real difference", "you can just use ram disks", etc., etc. > > > > Here is my plea... I am using a set of complicated CTEs to crawl through > > a network (tree) to aggregate and calculate formulas. I don't have > > exceptionally large datasets but my CTEs result in a ton of memory usage. > > The process works well from disk, in Windows, but using a smaller test > > sample I get about a 30% to 40% increase in processing time if I set the > > PRAGMA to temp_store = 2. If I use a normal dataset, not a small test, I > > hit an approximate 2G limit and get a "out of memory" message, which I > > understand is due to SQLite3.exe being 32-bit. I have found some 3rd > party > > 64-bit builds for SQLite3 (best found is 3.8.5) but they are out of date > > and don't allow all functionality that I am using. So, I do have a use > > case that requires 64-bit and I would see a significant increase in > speed. > > > > As to RAM disks, I work in a corporate environment that locks down user > > rights which precludes me from distributing a tool that requires the > > creation of a tool that needs administrator rights. I also, would like > to > > avoid having to compile it myself; I am not a software engineer. > > > > Thanks for your consideration. > > > > Richard > > This communication is the property of CenturyLink and may contain > > confidential or privileged information. Unauthorized use of this > > communication is strictly prohibited and may be unlawful. If you have > > received this communication in error, please immediately notify the > sender > > by reply e-mail and destroy all copies of the communication and any > > attachments. > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- Regards, Michael.j.Falconer. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
