Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.6, 10.11, 11.4, 11.8, 12.3
-
Related to performance
Description
MDEV-37788 was a huge correctness and performance improvement. However, some conversions of float and double were out of its scope, and so were some other macros in include/big_endian.h and include/little_endian.h. Here is an example:
|
include/big_endian.h |
#define float8get(V,M) do { double def_temp;\
|
((uchar*) &def_temp)[0]=(M)[7];\
|
((uchar*) &def_temp)[1]=(M)[6];\
|
((uchar*) &def_temp)[2]=(M)[5];\
|
((uchar*) &def_temp)[3]=(M)[4];\
|
((uchar*) &def_temp)[4]=(M)[3];\
|
((uchar*) &def_temp)[5]=(M)[2];\
|
((uchar*) &def_temp)[6]=(M)[1];\
|
((uchar*) &def_temp)[7]=(M)[0];\
|
(V) = def_temp; } while(0) |
|
|
#define ushortget(V,M) do { V = (uint16) (((uint16) ((uchar) (M)[1]))+\
|
((uint16) ((uint16) (M)[0]) << 8)); } while(0) |
For such code, compilers may emit byte-access functions. This was verified to be the case in MDEV-37148. The most efficient way to copy potentially unaligned data is to invoke memcpy(). This pattern was followed in MDEV-37788.
Also the InnoDB functions mach_double_write(), mach_double_read(), mach_float_write(), mach_float_read() had better be rewritten using the common conversion routines.
Attachments
Issue Links
- is blocked by
-
-
- Closed
-