Re: [sqlite] Updating on 32bit os slower than 64bit?

2012-07-17 Thread Jim "Jed" Dodgen 
Are theses tests being run on the same hardware?

On Tue, Jul 17, 2012 at 5:09 AM, Black, Michael (IS) <michael.bla...@ngc.com
> wrote:

> Something that might be useful is to strace that program   Use  the "-c"
> switch to summarize the system calls first.  Then use the "-tt" to show
> relative timestamps to identify specific bottlenecks.
>
>
>
> Also, set up a ram disk on the system and see if that's slow too.  That
> will test the LVM idea.
>
>
>
> Also, try using  a memory database and see how that does.
>
>
>
> Differential diagnostics will get you there eventually.
>
>
>
> Michael D. Black
> Senior Scientist
> Advanced Analytics Directorate
> Advanced GEOINT Solutions Operating Unit
> Northrop Grumman Information Systems
>
> 
> From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org]
> on behalf of xp [needforspeed1...@gmail.com]
> Sent: Monday, July 16, 2012 10:11 AM
> To: sqlite-users@sqlite.org
> Subject: EXT :Re: [sqlite] Updating on 32bit os slower than 64bit?
>
> Michael,
>
> Thanks for your reply.  My /home is not NFS mounted. It is mounted locally
> using LVM. I just tested on another 32 bit linux system (rhel 5, not using
> LVM). It ran much faster than the 32 bit fedora, not as fast as the 64 bit
> scientific linux but close. I also tried to test on /tmp on the fedora, but
> it is very slow. The /tmp is also mounted using LVM.  Do you think LVM
> might
> be the problem?
>
> Thanks!
>
> --
> View this message in context:
> http://sqlite.1065341.n5.nabble.com/Updating-on-32bit-os-slower-than-64bit-tp63292p63313.html
> Sent from the SQLite mailing list archive at Nabble.com.
> ___
> 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
>



-- 

*Jim Dodgen*


*
*
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Updating on 32bit os slower than 64bit?

2012-07-17 Thread Black, Michael (IS) 
Something that might be useful is to strace that program   Use  the "-c" switch 
to summarize the system calls first.  Then use the "-tt" to show relative 
timestamps to identify specific bottlenecks.



Also, set up a ram disk on the system and see if that's slow too.  That will 
test the LVM idea.



Also, try using  a memory database and see how that does.



Differential diagnostics will get you there eventually.



Michael D. Black
Senior Scientist
Advanced Analytics Directorate
Advanced GEOINT Solutions Operating Unit
Northrop Grumman Information Systems


From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on 
behalf of xp [needforspeed1...@gmail.com]
Sent: Monday, July 16, 2012 10:11 AM
To: sqlite-users@sqlite.org
Subject: EXT :Re: [sqlite] Updating on 32bit os slower than 64bit?

Michael,

Thanks for your reply.  My /home is not NFS mounted. It is mounted locally
using LVM. I just tested on another 32 bit linux system (rhel 5, not using
LVM). It ran much faster than the 32 bit fedora, not as fast as the 64 bit
scientific linux but close. I also tried to test on /tmp on the fedora, but
it is very slow. The /tmp is also mounted using LVM.  Do you think LVM might
be the problem?

Thanks!

--
View this message in context: 
http://sqlite.1065341.n5.nabble.com/Updating-on-32bit-os-slower-than-64bit-tp63292p63313.html
Sent from the SQLite mailing list archive at Nabble.com.
___
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

Re: [sqlite] Updating on 32bit os slower than 64bit?

2012-07-17 Thread xp 
I've tried to set the SQLITE_THREADSAFE=2 and 1, but observed no difference.
Any other flag that might affect this?  Thanks

--
View this message in context: 
http://sqlite.1065341.n5.nabble.com/Updating-on-32bit-os-slower-than-64bit-tp63292p63319.html
Sent from the SQLite mailing list archive at Nabble.com.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Updating on 32bit os slower than 64bit?

2012-07-17 Thread xp 
Michael,

Thanks for your reply.  My /home is not NFS mounted. It is mounted locally
using LVM. I just tested on another 32 bit linux system (rhel 5, not using
LVM). It ran much faster than the 32 bit fedora, not as fast as the 64 bit
scientific linux but close. I also tried to test on /tmp on the fedora, but
it is very slow. The /tmp is also mounted using LVM.  Do you think LVM might
be the problem?

Thanks!

--
View this message in context: 
http://sqlite.1065341.n5.nabble.com/Updating-on-32bit-os-slower-than-64bit-tp63292p63313.html
Sent from the SQLite mailing list archive at Nabble.com.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Updating on 32bit os slower than 64bit?

2012-07-16 Thread Jonas Malaco Filho 
Could be different compilation settings for sqlite (or libs).

*Jonas Malaco Filho*



2012/7/15 xp 

> Hi,
>
> I am a sqlite newbie. I would be very grateful if anyone can answer my
> question or point me to the right direction.
>
> I have a very simple database:
>
> create table epics_channel(
>   id integer primary key,
>   epics_pv text unique,
>   value_type text,  -- current or voltage
>   value real default 0.0
> );
> - Populate EPICS channel table --
> insert into epics_channel(epics_pv, value_type) values ('01QM000I01',
> 'current');
> insert into epics_channel(epics_pv, value_type) values ('01MP001I01',
> 'current');
> insert into epics_channel(epics_pv, value_type) values ('01MP002I01',
> 'current');
> insert into epics_channel(epics_pv, value_type) values ('01MP003I01',
> 'current');
> insert into epics_channel(epics_pv, value_type) values ('02MP001I01',
> 'current');
> insert into epics_channel(epics_pv, value_type) values ('02MP002I01',
> 'current');
> insert into epics_channel(epics_pv, value_type) values ('02MP003I01',
> 'current');
> insert into epics_channel(epics_pv, value_type) values ('02MP004I01',
> 'current');
> insert into epics_channel(epics_pv, value_type) values ('02MP005I01',
> 'current');
> insert into epics_channel(epics_pv, value_type) values ('02MP006I01',
> 'current');
>
> And a single c++ code to update the database:
>
>  sqlite3* db;
>   char* errmsg;
>   sqlite3_open("example.db", );
>   sqlite3_enable_load_extension(db, 1);
>   const char* lib = "./libsqliteext.so";
>   sqlite3_load_extension(db, lib, 0, );
>
>   std::string sql;
>   sqlite3_stmt* stmt;
>
>   for(int j = 1; j <=10; ++j )
>   {
> std::stringstream val;
> std::stringstream id;
> val << a_number; id << j;
> sql = "update epics_channel set value = " + val.str() + " where id = "
> +
> id.str();
> sqlite3_prepare(db, sql.c_str(), -1, , NULL);
> sqlite3_step(stmt);
> sqlite3_finalize(stmt);
>   }
>
> I ran the same code on a 64bit(scientific linux 6.1) and a 32bit(fedora 17)
> linux box. it took 0.113859 sec for the 64bit system to finish, but 14.4922
> sec for the 32bit fedora 17.  Can anyone tell me why it was so slow on the
> 32bit system?
> And I noticed this only happened for the "update". If I use "select", it
> took both systems about the same time to finish.
>
>
> --
> View this message in context:
> http://sqlite.1065341.n5.nabble.com/Updating-on-32bit-os-slower-than-64bit-tp63292.html
> Sent from the SQLite mailing list archive at Nabble.com.
> ___
> 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

Re: [sqlite] Updating on 32bit os slower than 64bit?

2012-07-16 Thread Black, Michael (IS) 
Wow...14 secs for 10 updates?  That's the slowest I've ever heard by far.



Is your 32-bit system using an NFS mounted /home or such?



Can you run your test on /tmp instead?





Michael D. Black
Senior Scientist
Advanced Analytics Directorate
Advanced GEOINT Solutions Operating Unit
Northrop Grumman Information Systems


From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on 
behalf of xp [needforspeed1...@gmail.com]
Sent: Sunday, July 15, 2012 2:08 PM
To: sqlite-users@sqlite.org
Subject: EXT :[sqlite] Updating on 32bit os slower than 64bit?

Hi,

I am a sqlite newbie. I would be very grateful if anyone can answer my
question or point me to the right direction.

I have a very simple database:

create table epics_channel(
  id integer primary key,
  epics_pv text unique,
  value_type text,  -- current or voltage
  value real default 0.0
);
- Populate EPICS channel table --
insert into epics_channel(epics_pv, value_type) values ('01QM000I01',
'current');
insert into epics_channel(epics_pv, value_type) values ('01MP001I01',
'current');
insert into epics_channel(epics_pv, value_type) values ('01MP002I01',
'current');
insert into epics_channel(epics_pv, value_type) values ('01MP003I01',
'current');
insert into epics_channel(epics_pv, value_type) values ('02MP001I01',
'current');
insert into epics_channel(epics_pv, value_type) values ('02MP002I01',
'current');
insert into epics_channel(epics_pv, value_type) values ('02MP003I01',
'current');
insert into epics_channel(epics_pv, value_type) values ('02MP004I01',
'current');
insert into epics_channel(epics_pv, value_type) values ('02MP005I01',
'current');
insert into epics_channel(epics_pv, value_type) values ('02MP006I01',
'current');

And a single c++ code to update the database:

 sqlite3* db;
  char* errmsg;
  sqlite3_open("example.db", );
  sqlite3_enable_load_extension(db, 1);
  const char* lib = "./libsqliteext.so";
  sqlite3_load_extension(db, lib, 0, );

  std::string sql;
  sqlite3_stmt* stmt;

  for(int j = 1; j <=10; ++j )
  {
std::stringstream val;
std::stringstream id;
val << a_number; id << j;
sql = "update epics_channel set value = " + val.str() + " where id = " +
id.str();
sqlite3_prepare(db, sql.c_str(), -1, , NULL);
sqlite3_step(stmt);
sqlite3_finalize(stmt);
  }

I ran the same code on a 64bit(scientific linux 6.1) and a 32bit(fedora 17)
linux box. it took 0.113859 sec for the 64bit system to finish, but 14.4922
sec for the 32bit fedora 17.  Can anyone tell me why it was so slow on the
32bit system?
And I noticed this only happened for the "update". If I use "select", it
took both systems about the same time to finish.


--
View this message in context: 
http://sqlite.1065341.n5.nabble.com/Updating-on-32bit-os-slower-than-64bit-tp63292.html
Sent from the SQLite mailing list archive at Nabble.com.
___
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