Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Richard Hipp]

On Tue, Jun 3, 2014 at 8:34 AM, Max Vlasov  wrote:

> Don't know what is difference between "stock" 3.8.4.3 from the site
> and the newly compiled one...
>

The official deliveries of 32-bit DLLs are normally cross-compiled on Linux
using MinGW 4.5.2.  But the most recent snaphost 32-bit DLL was compiled on
Win8 using VS2012.

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

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Max Vlasov]

On Tue, May 27, 2014 at 10:49 PM, Richard Hipp  wrote:
> On Tue, May 27, 2014 at 10:50 AM, Richard Hipp  wrote:
>>
>
> This time I build the 32-bit DLL using mingw instead of MSVC.  (MSVC was
> still used for the 64-bit DLL.)  So perhaps it will work correctly on
> WinXP.  Please let me know one way or the other.  Thanks.
>

Don't know what is difference between "stock" 3.8.4.3 from the site
and the newly compiled one, but synthetic tests with memory databases
(no I/O involved) show that the new one is about 20% faster (Intel
Core i5-2310). If they're both MinGW built then probably some switch
differences between these builds (if there are any) gives such
difference.

Here is the schema and the timings. The first one is for
sqlite-dll-win32-x86-3080403.zip, the second one is for
sqlite-dll-win32-x86-201406021126.zip

The table in memory
  CREATE TABLE [TestTable] ([ID] Integer primary key, [IntValue]
INTEGER, [FloatValue] FLOAT, [StrValue] TEXT)

was populated  with 1000 pseudo-random rows using the same seed for
every test. The following queries all use cross join and differ in
types of data used (int, float, string)


Select Count(*) FROM (SELECT * FROM TestTable T1 Join TestTable T2 )
62 msec
47 msec

Select Count(*) FROM (SELECT *,t1.FloatValue / t2.FloatValue as
divvalue FROM TestTable T1 Join TestTable T2 where abs(divvalue -
round(divvalue)) > 0.499)
453 msec
359 msec

Select Count(*) FROM (SELECT * FROM TestTable T1 Join TestTable T2
where (T1.IntValue * T2.IntValue) % 1789 = 56)
203 msec
187 msec

Select Count(*) FROM (SELECT * FROM TestTable T1 Join TestTable T2
where substr(t1.strvalue, 1 + t1.intvalue % 20, 1 + t2.intvalue % 20)
= t2.strvalue)
499 msec
405 msec

Select Count(*) FROM (SELECT *,t1.FloatValue / t2.FloatValue as
divvalue FROM TestTable T1 Join TestTable T2 where abs(divvalue -
round(divvalue)) > 0.499 or (T1.IntValue * T2.IntValue) % 1789 = 56 or
substr(t1.strvalue, 1 + t1.intvalue % 20, 1 + t2.intvalue % 20) =
t2.strvalue)
1124 msec
952 msec


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

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Jan Nijtmans]

2014-05-29 15:52 GMT+02:00 Len Chisholm :
> I see that the 64-bit MSVC DLL has the correct version resources, which show
> in the tool-tip when you hover over the DLL in an Explorer window or look at
> the file properties.
> I think that I also got the version info when I went through the steps to
> compile my own DLL with MSVC a while ago.
> However, the latest 32-bit DLL compiled with mingw doesn't include the
> version info.

MinGW is only supported on best-effort base (unlike MSVC), so I have no
idea when Richard will handle this. It's already reported here:

The ML report contains a patch and explanation too. Feel free to try
it and ask questions here, I'll try to answer them.

> There is a ticket for this in the bug tracker, which I can't find right now,


Regards,
Jan Nijtmans
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Len Chisholm]

Hi all,

It was posted earlier that :


This time I build the 32-bit DLL using mingw instead of MSVC.  (MSVC was
still used for the 64-bit DLL.)  So perhaps it will work correctly on
WinXP.  Please let me know one way or the other.  Thanks.


I see that the 64-bit MSVC DLL has the correct version resources, which 
show in the tool-tip when you hover over the DLL in an Explorer window 
or look at the file properties.
I think that I also got the version info when I went through the steps 
to compile my own DLL with MSVC a while ago.
However, the latest 32-bit DLL compiled with mingw doesn't include the 
version info.


There is a ticket for this in the bug tracker, which I can't find right 
now, which is marked as 'closed/fixed' but there is obviously something 
missing from the mingw DLL build system.


I would really appreciate it if this could be sorted out - I have enough 
unidentifiable SQLite DLLs lying around as it is and there can't be much 
to fix.


Thanks,
Len Chisholm.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Edward Lau]

(sqlite3_vtab_cursor *)myVCur;


   ROWID=0;


   return   SQLITE_OK;
}


static
int   xClose(   sqlite3_vtab_cursor *pVTabCur )
{
   myVCursor *myVCur = (myVCursor *)pVTabCur;


   sqlite3_free( myVCur );


   return   SQLITE_OK;
}


static
int   xEof( sqlite3_vtab_cursor *pVTabCur )
{
   return   (ROWID >= MAX_ITERATION);
}


static
int   xNext(sqlite3_vtab_cursor *pVTabCur )
{
   ROWID++;


   return   SQLITE_OK;
}


static
int   xColumn(  sqlite3_vtab_cursor *pVTabCur ,sqlite3_context *pContext ,int 
pColID )
{
   switch( pColID )
   {
  case -1: sqlite3_result_int64(pContext ,ROWID );
   break;
  case  0: sqlite3_result_text( pContext ,sqlite3_mprintf("doMPrintf 1") 
,11 ,sqlite3_free );
   break;
  case  1: sqlite3_result_text( pContext ,sqlite3_mprintf("doMPrintf 2") 
,11 ,sqlite3_free );
   break;
  case  2: sqlite3_result_text( pContext ,sqlite3_mprintf("doMPrintf 3") 
,11 ,sqlite3_free );
   break;
  default: sqlite3_result_null( pContext );
   }


   return SQLITE_OK;
}


static
int   xRowid(   sqlite3_vtab_cursor *pVTabCur ,sqlite_int64 *pRowID )
{
   *pRowID= ROWID;


   return   SQLITE_OK;
}


static
int   xBestIndex( sqlite3_vtab *pVTable ,sqlite3_index_info *pIdxInfo )
{
   return   SQLITE_OK;
}


static
int   xFilter(  sqlite3_vtab_cursor *pVTabCur ,int pIdxNum ,const char *pIdxStr 
,int pArgc ,sqlite3_value **ppArgv )
{
   return   SQLITE_OK;
}


// End of SQLite3 Interface routines.


//
// A virtual table module that scan structure text file(s).
//
static   sqlite3_module myVModule = {
1 // iVersion
  // Table instance functions.
   ,xCreate   // xCreate - Required. Called when a virtual table 
instance is first created with the CREATE VIRTUAL TABLE command.
   ,xConnect  // xConnect- Required, but frequently the same as 
xCreate(). This is called when a database with an existing virtual table 
instance is loaded. Called once for each table instance.
   ,xBestIndex// xBestIndex  - Required. Called, sometimes several times, 
when the database engine is preparing an SQL statement that involves a virtual 
table.
   ,xDisconnect   // xDisconnect - Required. Called when a database containing 
a virtual table instance is detached or closed. Called once for each table 
instance.
   ,xDestroy  // xDestroy- Required, but frequently the same as 
xDisconnect(). This is called when a virtual table instance is destroyed with 
the DROP TABLE command.
  // Cursor functions.
   ,xOpen // xOpen   - Required. Called to create and initialize a 
table cursor.
   ,xClose// xClose  - Required. Called to shut down and release a 
table cursor.
   ,xFilter   // xFilter - Required. Called to initiate a table scan 
and provide information about any specific conditions put on this particular 
table scan.
   ,xNext // xNext   - Required. Called to advance a table cursor 
to the next row.
   ,xEof  // xEof- Required. Called to see if a table cursor 
has reached the end of the table or not. This function is always called right 
after a call to xFilter() or xNext().
   ,xColumn   // xColumn - Required. Called to extract a column value 
for the current row. Normally called multiple times per row.
   ,xRowid// xRowid  - Required. Called to extract the virtual 
ROWID of the current row.
  //
   ,0 // xUpdate
  // Transaction control functions.
   ,0 // xBegin
   ,0 // xSync
   ,0 // xCommit
   ,0 // xRollback
  //
   ,0 // xFindFunction
   ,xRename   // xRename - Required. Called when a virtual table is 
renamed using the ALTER TABLE...RENAME command.
   ,0 // xSavepoint
   ,0 // xRelease
   ,0 // xRollbackTo
};


// Extension load function entry point.
//
int   myVirtualTable_init(sqlite3 *db ,char **ppzErrMsg ,const 
sqlite3_api_routines *pApi )
{
  inti;
  char  *moduleName = "benchmark";


  SQLITE_EXTENSION_INIT2( pApi );


  return   sqlite3_create_module( db ,moduleName , ,NULL );
}


// Default entry point which SQLite3 will look for when this module is loaded.
int   sqlite3_extension_init(sqlite3 *db ,char **ppzErrMsg ,const 
sqlite3_api_routines *pApi )
{
  return   myVirtualTable_init( db ,ppzErrMsg ,pApi );
}






-Original Message-
From: Warren Young <war...@etr-usa.com>
To: General Discussion of SQLite Database <sqlite-users@sqlite.org>
Sent: Wed, May 28, 2014 11:38 am
Subject: Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta


On 5/28/2014 12:26, Warren Young wrote:
> On 5/28/2014 11:20, jose isaias cabrera wrote:
>>
>> I would rather have the speed
>> then the size.
>
> in today's

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Baruch Burstein]

On Wed, May 28, 2014 at 9:43 PM, Richard Hipp  wrote:

> On Wed, May 28, 2014 at 1:20 PM, jose isaias cabrera
> wrote:
>
> >
> > 3. Is there a spot anywhere that has clear steps on creating the Sqlite3
> > DLL?
> >
>
> http://www.sqlite.org/draft/howtocompile.html#dll
>
> The "draft" page above will be promoted to the official website at the next
> release.

A comment on the draft: mingw64 has 32-bit compilers, too (they even have
32/64 mixed compilers), and they are generally more ahead than mingw as far
as gcc versions (they have had a gcc 4.9.0 compiler since it was in beta)


-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Baruch Burstein]

On Wed, May 28, 2014 at 8:09 PM, Richard Hipp  wrote:

> On Wed, May 28, 2014 at 12:56 PM, jose isaias cabrera <
> cabr...@wrc.xerox.com
> > wrote:
>
> >
> > Just noticed something...  It may be nothing, but the MinGW built DLL has
> > a size of 645KB while the MSVC built one has a size of 962KB.  Just under
> > 33% bigger. I hope there is nothing missing on the MinGW one. :-)  It's
> so
> > weird how MS DLLs and programs are always so much bigger in size then
> > non-MS built ones.  Just food for thoughts...
> >
>
> The MSVC DLL is 64-bit and the MinGW DLL is 32-bit.  That accounts for part
> of the difference.  Additionally, MinGW was run with the -Os option
> (optimize for small size) whereas MSVC was run with -O2 (optimize for
> maximum speed).  So MSVC is probably doing lots of function in-lining and
> loop-unrolling that might make the code a little faster, but also makes it
> bigger.
>

I compiled with mingw64 - a 64-bit DLL with -O2 is 650K


-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Baruch Burstein]

On Thu, May 29, 2014 at 3:55 AM, RSmith  wrote:

>
> On 2014/05/28 20:26, Warren Young wrote:
>
>> On 5/28/2014 11:20, jose isaias cabrera wrote:
>>
>>>
>>> I would rather have the speed
>>> then the size.
>>>
>>
>>
> Rather speed than size is an Engineering decision which is easy on a
> desktop/server system (such as most Windows/OSX/*nix implementations) but
> it may well be the opposite in a phone or other handheld device or small
> integrated system where IO is so significantly slower and size is paramount.

Since the comment was about the Windows DLL, it seems an easy decision (as
you said yourself) to prefer speed over size.

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[RSmith]

On 2014/05/28 20:26, Warren Young wrote:

On 5/28/2014 11:20, jose isaias cabrera wrote:


I would rather have the speed
then the size.




Rather speed than size is an Engineering decision which is easy on a desktop/server system (such as most Windows/OSX/*nix 
implementations) but it may well be the opposite in a phone or other handheld device or small integrated system where IO is so 
significantly slower and size is paramount. What's more, SQLite caters (and have always catered) for these embedded implementations 
- and while today on most ARM things or Android/iSomething systems size is becoming less of a concern than it historically was, 
SQLite's focus is still correctly aimed at un-bulk.


Many years ago, I read an article written by a Microsoft employee where they said they built Windows' own binaries optimized for 
size rather than speed, since in today's L1/L2/L3 world, size *is* speed.


Bigger code gets kicked out of the processor cache faster, so the processor has 
to go back to main memory more often.


Others have already responded with lots of caveats to this, but let me add to never confuse file size with resulting code size. One 
optimization may be to provide a few different versions of the same set of code bits that get used based on criteria. The people who 
make the optimizers are usually quite well versed in what makes for faster execution and/or size and it is unlikely that they will 
have made really bad choices as visible from the sideline by us forum dwellers - no matter which one of the OSes they mainly serve.




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

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Scott Robison]

On May 28, 2014 12:36 PM, "Drago, William @ MWG - NARDAEAST"
> Don't modern compilers consider what effects the speed optimizations will
have on the pipeline and the cache and optimize accordingly?

I think they might try to in a broad way, but we live in a world with
multiple models of CPUs from multiple manufacturers with varying amounts of
cache and varying pipeline details and so on. If you knew you could target
a specific CPU that would be possible, but usually you don't have the
needed information.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[jose isaias cabrera]

"Richard Hipp" wrote...


On Wed, May 28, 2014 at 1:20 PM, jose isaias cabrera
wrote:



3. Is there a spot anywhere that has clear steps on creating the Sqlite3
DLL?



http://www.sqlite.org/draft/howtocompile.html#dll

The "draft" page above will be promoted to the official website at the 
next

release.


Muchas gracias. 


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

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Richard Hipp]

On Wed, May 28, 2014 at 1:20 PM, jose isaias cabrera
wrote:

>
> 3. Is there a spot anywhere that has clear steps on creating the Sqlite3
> DLL?
>

http://www.sqlite.org/draft/howtocompile.html#dll

The "draft" page above will be promoted to the official website at the next
release.



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

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Warren Young]

On 5/28/2014 12:35, Drago, William @ MWG - NARDAEAST wrote:


Bigger code gets kicked out of the processor cache faster, so the
processor has to go back to main memory more often.


Don't modern compilers consider what effects the speed optimizations will have 
on the pipeline and the cache and optimize accordingly?


The compiler probably won't be looking at things like cache pressure. 
All the compiler will care about is that this function now executes 
twice as fast, yay!  It won't consider that it had to make it twice as 
large as the -Os version, which will therefore stay in cache 4x as long, 
so that cache thrashing will throw away the 2x benefit.


As you say, it probably won't make a function so large that it never 
fits into L1 in the first place.

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

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Warren Young]

On 5/28/2014 12:26, Warren Young wrote:

On 5/28/2014 11:20, jose isaias cabrera wrote:


I would rather have the speed
then the size.


in today's L1/L2/L3 world, size *is* speed.


Also, there is a pretty hard limit on how much micro code optimizations 
can help a DBMS.  It's a fundamentally I/O limited problem.  Disk is 
many (4ish?) orders of magnitude slower than main RAM, and the CPU 
caches are orders of magnitude faster than that.


http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html

That is to say, if you made every code path in SQLite zero length, it 
would do approximately *squat* to improve the time it takes to get your 
query results.


Only intelligent algorithms matter here, not micro-optimizations. 
Better indexes, smarter query planners, etc.

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

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Drago, William @ MWG - NARDAEAST]

> -Original Message-
> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> boun...@sqlite.org] On Behalf Of Warren Young
> Sent: Wednesday, May 28, 2014 2:26 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5
> beta
>
> On 5/28/2014 11:20, jose isaias cabrera wrote:
> >
> > I would rather have the speed
> > then the size.
>
> Many years ago, I read an article written by a Microsoft employee where
> they said they built Windows' own binaries optimized for size rather
> than speed, since in today's L1/L2/L3 world, size *is* speed.
>
> Bigger code gets kicked out of the processor cache faster, so the
> processor has to go back to main memory more often.

Don't modern compilers consider what effects the speed optimizations will have 
on the pipeline and the cache and optimize accordingly?

-Bill




CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and any 
attachments are solely for the use of the addressee and may contain information 
that is privileged or confidential. Any disclosure, use or distribution of the 
information contained herein is prohibited. In the event this e-mail contains 
technical data within the definition of the International Traffic in Arms 
Regulations or Export Administration Regulations, it is subject to the export 
control laws of the U.S.Government. The recipient should check this e-mail and 
any attachments for the presence of viruses as L-3 does not accept any 
liability associated with the transmission of this e-mail. If you have received 
this communication in error, please notify the sender by reply e-mail and 
immediately delete this message and any attachments.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Scott Robison]

On Wed, May 28, 2014 at 12:26 PM, Warren Young  wrote:

> On 5/28/2014 11:20, jose isaias cabrera wrote:
>
>>
>> I would rather have the speed
>> then the size.
>>
>
> Many years ago, I read an article written by a Microsoft employee where
> they said they built Windows' own binaries optimized for size rather than
> speed, since in today's L1/L2/L3 world, size *is* speed.
>
> Bigger code gets kicked out of the processor cache faster, so the
> processor has to go back to main memory more often.
>

Good point. Many people fail to take into account that the real key to
speed is not what tricks a compiler can perform while translating code from
source to object form, but what algorithms are used in the source code. A
highly optimizing slow algorithm is rarely if ever going to outperform a
better algorithm.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Warren Young]

On 5/28/2014 11:20, jose isaias cabrera wrote:


I would rather have the speed
then the size.


Many years ago, I read an article written by a Microsoft employee where 
they said they built Windows' own binaries optimized for size rather 
than speed, since in today's L1/L2/L3 world, size *is* speed.


Bigger code gets kicked out of the processor cache faster, so the 
processor has to go back to main memory more often.

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

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[jose isaias cabrera]

"Richard Hipp" wrote...

On Wed, May 28, 2014 at 12:56 PM, jose isaias cabrera 

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Richard Hipp]

On Wed, May 28, 2014 at 12:56 PM, jose isaias cabrera  wrote:

>
> Just noticed something...  It may be nothing, but the MinGW built DLL has
> a size of 645KB while the MSVC built one has a size of 962KB.  Just under
> 33% bigger. I hope there is nothing missing on the MinGW one. :-)  It's so
> weird how MS DLLs and programs are always so much bigger in size then
> non-MS built ones.  Just food for thoughts...
>

The MSVC DLL is 64-bit and the MinGW DLL is 32-bit.  That accounts for part
of the difference.  Additionally, MinGW was run with the -Os option
(optimize for small size) whereas MSVC was run with -O2 (optimize for
maximum speed).  So MSVC is probably doing lots of function in-lining and
loop-unrolling that might make the code a little faster, but also makes it
bigger.


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

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[jose isaias cabrera]

"Richard Hipp" wrote...



On Tue, May 27, 2014 at 10:50 AM, Richard Hipp  wrote:


On Tue, May 27, 2014 at 10:39 AM, jose isaias cabrera <
cabr...@wrc.xerox.com> wrote:


H... I am running the original DLL created for 3.8.4.3 on the WinXP
and
it works fine, so it was not a change as far as v3.17 and before, but 
just

this new DLL.  I am wondering if it is also because it is a pre-release
and
the "released" version will work fine.



It is probably because Dan usually builds the release DLLs using mingw
(32-bit) but I built those pre-release DLLs using MSVC 2012.



Fresh DLLs (and source code) with all the latest updates and enhancements
are now on the website:  http://www.sqlite.org/download.html

This time I build the 32-bit DLL using mingw instead of MSVC.  (MSVC was
still used for the 64-bit DLL.)  So perhaps it will work correctly on
WinXP.  Please let me know one way or the other.  Thanks.


Just noticed something...  It may be nothing, but the MinGW built DLL has a 
size of 645KB while the MSVC built one has a size of 962KB.  Just under 33% 
bigger. I hope there is nothing missing on the MinGW one. :-)  It's so weird 
how MS DLLs and programs are always so much bigger in size then non-MS built 
ones.  Just food for thoughts...


Thanks.
josé 


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

Re: [sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[jose isaias cabrera]

"Richard Hipp" wrote...



On Tue, May 27, 2014 at 10:50 AM, Richard Hipp  wrote:


On Tue, May 27, 2014 at 10:39 AM, jose isaias cabrera <
cabr...@wrc.xerox.com> wrote:


H... I am running the original DLL created for 3.8.4.3 on the WinXP
and
it works fine, so it was not a change as far as v3.17 and before, but 
just

this new DLL.  I am wondering if it is also because it is a pre-release
and
the "released" version will work fine.



It is probably because Dan usually builds the release DLLs using mingw
(32-bit) but I built those pre-release DLLs using MSVC 2012.



Fresh DLLs (and source code) with all the latest updates and enhancements
are now on the website:  http://www.sqlite.org/download.html

This time I build the 32-bit DLL using mingw instead of MSVC.  (MSVC was
still used for the 64-bit DLL.)  So perhaps it will work correctly on
WinXP.  Please let me know one way or the other.  Thanks.


Thanks, Dr. Hipp.  This new DLL works like a charm.

josé 


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

[sqlite] New DLLs and sources. Was: SQLite version 3.8.5 beta

[Richard Hipp]

On Tue, May 27, 2014 at 10:50 AM, Richard Hipp  wrote:
>
> On Tue, May 27, 2014 at 10:39 AM, jose isaias cabrera <
> cabr...@wrc.xerox.com> wrote:
>
>> H... I am running the original DLL created for 3.8.4.3 on the WinXP
>> and
>> it works fine, so it was not a change as far as v3.17 and before, but just
>> this new DLL.  I am wondering if it is also because it is a pre-release
>> and
>> the "released" version will work fine.
>
>
> It is probably because Dan usually builds the release DLLs using mingw
> (32-bit) but I built those pre-release DLLs using MSVC 2012.
>
>
Fresh DLLs (and source code) with all the latest updates and enhancements
are now on the website:  http://www.sqlite.org/download.html

This time I build the 32-bit DLL using mingw instead of MSVC.  (MSVC was
still used for the 64-bit DLL.)  So perhaps it will work correctly on
WinXP.  Please let me know one way or the other.  Thanks.



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