I also tried it.. The result is just like the same with /tmp Total time to insert 100.000 data into database:
ramdisk: 69860 ms memory: 9606 ms Serdar On Wed, Nov 4, 2009 at 12:14 PM, Abel, John <john.a...@bbusl.com> wrote: > Hi Serdar, > > For Solaris, you need: > > ramdiskadm -a mydisk 2m > newfs /dev/rramdisk/mydisk > mkdir /mnt/ramDisk > mount /dev/ramdisk/mydisk /mnt/ramDisk > > > John > > -----Original Message----- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Serdar Genc > Sent: 04 November 2009 09:13 > To: General Discussion of SQLite Database > Subject: Re: [sqlite] in-memory database concept > > Yes you are right about it but when I tried to mount a place as tmpfs, > its > type seemed swap just like /tmp. > The speed seems to be same with /tmp. What I need to increase the speed > for > /tmp or another solution for > in-memory database. > > Serdar > > On Wed, Nov 4, 2009 at 10:56 AM, Stephan Wehner > <stephanweh...@gmail.com>wrote: > > > On Wed, Nov 4, 2009 at 12:51 AM, Serdar Genc <serdar.g...@gmail.com> > > wrote: > > > The OS that I am implementing this is SunOS and I have already tried > > doing > > > it by creating the file in /tmp but > > > but because of file I/O operations to reach /tmp. The speed of > sqlite is > > > significantly slow (memory is 5 times faster than file system). > Speed of > > > Sqlite is important for me. That's why I still working on the memory > > issue. > > > > > > > Hi there, > > > > /tmp is not the same as tmpfs -- tmpfs is a file system that stores > > files in RAM, but looks otherwise like any other file system. > > > > On SunOS it should be straightforward; that wiki page says "SunOS, and > > later Solaris, include probably the earliest implementations of > > tmpfs". > > > > Stephan > > > > > Thanks for the answer, > > > Serdar Genc > > > > > > On Wed, Nov 4, 2009 at 10:45 AM, Stephan Wehner > <stephanweh...@gmail.com > > >wrote: > > > > > >> On Wed, Nov 4, 2009 at 12:27 AM, Serdar Genc > <serdar.g...@gmail.com> > > >> wrote: > > >> > Hello everyone, > > >> > > > >> > I have a little bit problem about in-memory database feature of > > SQLite. I > > >> > would like to use two programming languages in my application . > > >> > These languages will be Java and C++. I would like to reach the > same > > >> > database in memory by using both. I used Xerial for JDBC for > Java. > > >> > Everything seems fine if I am using a regular file on harddrive. > I can > > >> write > > >> > data from C++ process and read these data from Java. > > >> > But when I try to do this for in-memory, everything is getting > chunky. > > A > > >> new > > >> > database is being created in memory for every attempt to open > > >> > database in memory. Now I am trying to switch the database > handler > > >> between > > >> > C++ and Java. It requires some efforts. > > >> > > > >> > What I want to try to reach the same database in memory from two > > threads > > >> or > > >> > processes and these would be in different programming languages. > > >> > Any different idea how to implement this is appreciated.. > > >> > > >> Can you use a RAM based file system? > > >> > > >> http://en.wikipedia.org/wiki/Tmpfs > > >> > > >> Stephan > > >> > > >> > Thanks in advance, > > >> > Serdar Genc > > >> > _______________________________________________ > > >> > sqlite-users mailing list > > >> > sqlite-users@sqlite.org > > >> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > >> > > > >> > > >> > > >> > > >> -- > > >> Stephan Wehner > > >> > > >> -> http://stephan.sugarmotor.org (blog and homepage) > > >> -> http://loggingit.com > > >> -> http://www.thrackle.org > > >> -> http://www.buckmaster.ca > > >> -> http://www.trafficlife.com > > >> -> http://stephansmap.org -- http://blog.stephansmap.org > > >> _______________________________________________ > > >> 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 > > > > > > > > > > > -- > > Stephan Wehner > > > > -> http://stephan.sugarmotor.org (blog and homepage) > > -> http://loggingit.com > > -> http://www.thrackle.org > > -> http://www.buckmaster.ca > > -> http://www.trafficlife.com > > -> http://stephansmap.org -- http://blog.stephansmap.org > > _______________________________________________ > > 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 > > > This message has been scanned for viruses by BlackSpider MailControl - > www.blackspider.com > > Balfour Beatty Utility Solutions Limited > > Registered Office 01062438: Park Square, Newton Chambers Road, Thorncliffe > Park, Chapeltown, Sheffield, S35 2PH. > > Registered Office 02067112: West Service Road, Raynesway, Derby, DE21 7BG. > > An agent of Balfour Beatty Group Limited. > Registered Office 101073: 130 Wilton Road, London, SW1V 1LQ. > > Place of Registration: Registered in England and Wales > > © 2007 Balfour Beatty Power Networks Ltd. trading as Balfour Beatty Utility > Solutions > > _______________________________________________ > 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
