Kees Nuyt <[EMAIL PROTECTED]> writes:
>
> Just a suggestion: Perhaps even on the home page.
>
> "This the homepage for SQLite - a library that implements a
> self-contained, serverless, zero-configuration, _portable_,
> transactional SQL database engine."
>
> With a link to a 'Portable'
On Tue, 27 Nov 2007 14:54:32 +, [EMAIL PROTECTED] wrote:
>Jarl Friis <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] writes:
>>
>> >
>> > The file format is portable.
>> >
>> > However, if you store UTF16le data, there is a performance
>> > penalty for extracting it on a UTF16be machine.
>>
Jarl Friis <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
> >
> > The file format is portable.
> >
> > However, if you store UTF16le data, there is a performance
> > penalty for extracting it on a UTF16be machine.
>
> Thanks. That made the answer very clear. Could that clear
[EMAIL PROTECTED] writes:
>
> The file format is portable.
>
> However, if you store UTF16le data, there is a performance
> penalty for extracting it on a UTF16be machine.
Thanks. That made the answer very clear. Could that clear information
be put somewhere in the documetation pages or wiki.
Jarl Friis <[EMAIL PROTECTED]> wrote:
> "Nuno Lucas" <[EMAIL PROTECTED]> writes:
>
> > If you will be sharing databases between different endienness
> > systems then you care, so you will take appropriate actions to have
> > the best result. The same is true with any other portable file
> >
On Nov 27, 2007, at 7:26 PM, Jarl Friis wrote:
"Nuno Lucas" <[EMAIL PROTECTED]> writes:
If you will be sharing databases between different endienness
systems then you care, so you will take appropriate actions to have
the best result. The same is true with any other portable file
format.
"Nuno Lucas" <[EMAIL PROTECTED]> writes:
> If you will be sharing databases between different endienness
> systems then you care, so you will take appropriate actions to have
> the best result. The same is true with any other portable file
> format.
So my question boils down to: Is the SQLite
result. The same is true with any other portable file format.
Regards,
~Nuno Lucas
>
> Best regards,
> Igor
>
>
>
>
> -Original Message-
> From: Nuno Lucas [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 23, 2007 2:01 PM
> To: sqlite-users@sqlite.org
&g
"Igor Sereda" <[EMAIL PROTECTED]> writes:
>> About the endieness, you don't need to know if you
>> don't care. SQLite handles it.
Does SQLite really handle that? or does SQLite just delegate the
handling to the underlying OS, which in turn delegates the handling to
the underlying Hardware. If
reated on Intel-based
system and then moved to Mac/PPC.
Best regards,
Igor
-Original Message-
From: Nuno Lucas [mailto:[EMAIL PROTECTED]
Sent: Friday, November 23, 2007 2:01 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] benchmarking UTF8 vs UTF16 encoded databases
On 11/23/07
On 11/23/07, Jarl Friis <[EMAIL PROTECTED]> wrote:
> Hi Daniel.
>
> Thanks for the benchmark reports, interesting studies.
>
> Another reason to stay away from utf-16 is that it is not endianess
> neutral. Which raise the question are you storing in UTF-16BE or
> UTF-16LE ?
If you only speak
Hi Daniel.
Thanks for the benchmark reports, interesting studies.
Another reason to stay away from utf-16 is that it is not endianess
neutral. Which raise the question are you storing in UTF-16BE or
UTF-16LE ?
Jarl
-
On Nov 22, 2007 1:04 PM, Daniel Önnerby <[EMAIL PROTECTED]> wrote:
> In the future I am using UTF8 encoded databases since the conversion of
> strings is a small thing for the system. The advantages of using UTF8
> are many:
> 1. Faster in most cases
> 2. Smaller databases (30% smaller in
When I started using SQLite I found it natural to use the sqlite3_open16
and use UTF16 encoding on strings since my applications always use
wchar_t when handeling strings. I never questioned this until now when I
decided to do some benchmark, and I found it interesting enough to share
with
14 matches
Mail list logo
