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?
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. Thanks. Mike -----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Richard Hipp Sent: Thursday, October 17, 2013 8:42 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] Trying to figure out how to circumvent sqlite3_win32_mbcs_to_utf8 On Thu, Oct 17, 2013 at 8:31 AM, Mike Clagett <mike.clag...@mathworks.com>wrote: > Hi -- > > Okay. It looks like sqlite3_win32_mbcs_to_utf8() is being called > from a number of functions, including sqlite3_value_blob, sqlite3_randomness, > sqlite3_extended_errcode, and sqlite3_os_init. From a spot check of the > execution trace it looks like sqlite3_os_init is probably the most > frequent caller. But tons and tons of calls to this function are > being made, often within the scope of a single prepared statement execution. > > Here's a pretty typical sample piece of the execution trace: > > > sqldb::sqlite::Sqlite3PreparedStatement::execute > > sqlite3_step > > sqlite3_declare_vtab > > sqlite3_declare_vtab > This trace looks wrong. sqlite3_step() shouldn't ever be calling sqlite3_declare_vtab(). And sqlite3_declare_vtab() is not recursive. Perhaps your debugger is only seeing exported symbols and is identifying internal routines using the nearest exported symbol? -- D. Richard Hipp d...@sqlite.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
