On Thu, Oct 17, 2013 at 9:37 AM, Mike Clagett <mike.clag...@mathworks.com>wrote:

> Hi --
>
> Okay.  This is helpful.   It appears the profiler is not doing such a good
> job at name resolution.  So I've been looking down a wrong path.   However,
> there definitely is a problem; whether or not I run the profiler, the app
> is taking a huge amount of time to execute.   So I don't think the profiler
> is causing the problem.   Do you have any ideas about how I might be able
> to diagnose this?   Is there something I can add to the picture to give the
> profiler a better chance to resolve the symbols correctly?  Or is there an
> alternate way to identify the code spots that are adding this execution
> time?
>

This suggests that it isn't really sqlite3_win32_msbc_to_utf8() that is
causing the problem.  Instead, it is probably some nearby routine like
winRead() ro winWrite() - routines that are doing actual file I/O.

I'm guessing you have some SQL that is doing a full table scan rather than
using an index.  The solution is probably just an appropriate CREATE INDEX
statement.

Consider activating the sqlite3_profile() callback (
http://www.sqlite.org/c3ref/profile.html) in order to see what SQL
statements you are running and how long each is taking.  That might give a
better clue that your profiler.

Or activate the sqlite3_trace() callback and use that to capture a script
of the SQL you are running.  The reply that script using the SQLite
command-line shell after activating the ".timer on" command and/or the
".stats on" command to get a better idea of which SQL statement or
statements are running slow.

Or make use of the sqlite3_stmt_status() API (
http://www.sqlite.org/c3ref/stmt_status.html) to find one which SQL
statements are doing full table scan or creating automatic indices, or
doing large sorts, etc.


>
> You mentioned in your first message turning on logging.   I've read the
> link and am going to do this.   But perhaps you could save me some time by
> verifying my understanding.   I am writing a component that is called from
> a larger application.  I do not have the opportunity to register anything
> at the start of the app (or at least I'm not aware of the mechanism to do
> this).  My code is being invoked from an internal application command line
> long after the app itself has launched.  So I would like to activate error
> logging at the initialization of my component.   Am I correct to assume
> that I can issue this sqlite3_config statement right before I create my
> database and that as long as my code is the only code using sqlite, this
> will have the desired effect and install my callback?   Clarification of
> this would be helpful.
>

Yes, I believe that is correct.

Of course, our point of view is that SQLite should be a built-in standard
component of Matlab so that a full-blown SQL database engine would be
available to all Matlab users without having to load an extension or
configure an external server.  In that case, error logging could be enabled
at application launch.  :-)

-- 
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to