On Wed, Dec 26, 2012 at 5:24 PM, Elefterios Stamatogiannakis <[email protected]> wrote: > On 26/12/2012 12:48 μμ, Maciej Fijalkowski wrote: >> >> On Mon, Dec 17, 2012 at 10:42 PM, Maciej Fijalkowski <[email protected]> >> wrote: >>> >>> On Mon, Dec 17, 2012 at 3:46 PM, Eleytherios Stamatogiannakis >>> <[email protected]> wrote: >>>> >>>> We had a "bug" in our previous benchmark ("mspw_bench.sql"). The way it >>>> was >>>> written allowed SQLite to short-circuit column data retrieval, ending up >>>> with minimal exercising of the CFFI layer. >>> >>> >>> I thought it was a feature :) >> >> >> Hi Elefterios. >> >> We've been working towards improving the situation of this benchmark. >> There is a branch done by antonio cuni and there are a few smaller >> things that will be improved in some time. Stay tuned. >> >> Cheers, >> fijal >> > > Thank you for looking into this part of pypy's performance. Whenever > something reaches a testable state we would be glad to test/benchmark it. > > On another front. We tried using SQLite's UTF-16 API to avoid doing the > conversion to UTF-8 whenever we returned a string from pypy to SQLite. We > used function "sqlite3_result_text16": > > http://www.sqlite.org/c3ref/result_blob.html > > defining it in CFFI as: > > void sqlite3_result_text16(sqlite3_context*, wchar_t*, int, void(*)(void*)); > > The problem was that giving directly a pypy string to above function (using > wchar_t type), only the first character of the string was passed to SQLite. > > The only way to successfully pass a string to SQLite was by explicitly > converting/encoding it to utf-16. > > So the question i have is, does pypy keep its strings internally to utf-16? > > Thanks again (and a happy new year) to all. > > l.
Are you talking about strings or unicodes? that is, type str or unicode? _______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
