[PATCH] Remove unncessary localtime() calls during data type conversion
От | Nikhil Deshpande |
---|---|
Тема | [PATCH] Remove unncessary localtime() calls during data type conversion |
Дата | |
Msg-id | 557B7C76.1030502@vmware.com обсуждение исходный текст |
Ответы |
Re: [PATCH] Remove unncessary localtime() calls during data
type conversion
|
Список | pgsql-odbc |
Hi, While doing some profiling work on an ODBC client, we noticed tons of libc localtime() and __tz_convert() calls on a hot code path (SQLFetch()), but most of the fields being retrieved were not of date/time type. These libc calls are costly (non-trivial work in terms of string ops, timzone conversion etc.) and the cost adds up quickly for high-frequency call like SQLFetch(). We noticed that this penalty is paid even for data types which aren't date/time related. Code inspection showed localtime() call in convert.c:copy_and_convert_field() at function start, being invoked regardless of whether output of localtime() is used or not. Attached is a non-intrusive patch that moves the call down to where it's needed (for both getting data from server and sending data to server), but I'm not sure if the patch is complete (it covers the case where source data type is time but destination needs date part, "TIME->DATE[TIME]"). Could you please review this patch and modify it for correctness and consider for committing it? --- A longer term cleaner approach would be to refactor the code to aim for at most one call to localtime() (e.g. if it's already invoked once in copy_and_convert_field() before, reuse that data). However that is much more intrusive change. I checked the test/src/result-conversions-test.c code and the test case specific to this scenario is commented out (since it the expected result would depend on actual current date). I un-commented those test cases, ran the test with and without my patch and got same results. Also the data looks ok for "TIME->DATE[TIME]" case, input is time, output is date. 1114a1176 > '13:23:34' (time) as SQL_C_TYPE_DATE: y: 2015 m: 6 d: 12 2015-6-12 is indeed current date. Thanks, Nikhil
Вложения
В списке pgsql-odbc по дате отправления: