Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Running slow on metro
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Ari H-C  
View profile   Translate to Translated (View Original)
 More options Jul 24 2012, 4:35 pm
From: Ari H-C <ari.hausmanco...@gmail.com>
Date: Tue, 24 Jul 2012 13:35:36 -0700 (PDT)
Local: Tues, Jul 24 2012 4:35 pm
Subject: Re: Running slow on metro

I found my problem; the ORDER BY operation is apparently extremely
expensive. As soon as I took it out things went more smoothly. It would
still be nice to somehow reduce the file checking though, as it probably
could still improve performance some.

On Tuesday, July 24, 2012 1:03:56 PM UTC-5, Ari H-C wrote:

> Hello, I'm looking to use this project in my windows 8 metro app, due to
> it being compatible with all processors, but it seems to be running
> incredibly slow (as much as 10x by comparison to sqlite-net (
> https://github.com/praeclarum/sqlite-net) in conjunction with the sqlite
> x64/x86 dlls. From what I can tell, this may due to a large number of
> "FileExists" checks, which require forcing synchronicity on to an async
> task (which is good because I want the synchronous behavior, but presumably
> might take a bit of extra time) and catching an error. Most of these calls
> seem to be related to the journaling feature. As I am only ever reading
> from my databases, I don't need this, and could even work with a readonly
> connection if that would indeed be faster. In general there seem to be a
> couple other async tasks being waited upon, including some pure time delays
> (though I have no idea if any of these are contributing to the slowness).
> Another cause may be that I am making several single row lookups instead of
> getting several rows with one call, due to the nature of my data handling.
> I have tried keeping the connection open and using the same one for all the
> calls, but it seems to have no noticeable improvement.
> Has any one else had such issues? Are there any thoughts on how I can
> improve the performance? As I posted in a thread yesterday, I think for a
> start readonly/no journaling might be helpful, but I can't figure out how
> to make the database behave as such.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.