-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
CLN: use integer parsing functions from stdlib #62658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
c3cc4a1
2459313
d8a454e
87789e6
2287944
2bea3c2
fb38679
f9ede5c
798c263
2f06f19
280b55e
d85aaf0
9046ecc
a4e2fb8
ef82cf4
5afeb11
0ef47a7
c840ef0
132342b
e6977cc
8120eea
1f5d506
479a2ab
c37c355
7d55283
ffe50ce
af5ad71
9211704
d026b01
d76ff5f
b523a19
6265172
abed6c1
8616f9f
c4e0e25
0b19208
29d74f7
b5b8f3b
803a8bf
31f26cf
171b553
30f6bdc
554675b
7ea4454
82dc037
627df4c
1b3eba0
e1667fa
bee776a
d693345
593c614
ff4d48b
e3a88d3
b135738
ba8c9b3
818921f
3e067f7
c0ed83c
cb60adb
5117e89
e1e327a
ffcb7c2
47b87f9
cd536fb
1ef9259
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -23,6 +23,7 @@ GitHub. See Python Software Foundation License and BSD licenses for these. | |||||
| #include <float.h> | ||||||
| #include <math.h> | ||||||
| #include <stdbool.h> | ||||||
| #include <stdlib.h> | ||||||
|
|
||||||
| #include "pandas/portable.h" | ||||||
| #include "pandas/vendored/klib/khash.h" // for kh_int64_t, kh_destroy_int64 | ||||||
|
|
@@ -1834,201 +1835,178 @@ int uint64_conflict(uint_state *self) { | |||||
| return self->seen_uint && (self->seen_sint || self->seen_null); | ||||||
| } | ||||||
|
|
||||||
| /** | ||||||
| * @brief Check if the character in the pointer indicates a number. | ||||||
| * It expects that you consumed all leading whitespace. | ||||||
| * | ||||||
| * @param p_item Pointer to verify | ||||||
| * @return Non-zero integer indicating that has a digit 0 otherwise. | ||||||
| */ | ||||||
| static inline int has_digit_int(const char *str) { | ||||||
|
||||||
| static inline int has_digit_int(const char *str) { | |
| static inline bool has_digit_int(const char *str) { |
We are far enough removed from C89 that we can use the bool type :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 87789e6
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will violate bounds checking if you pass a string of + or -
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For performance reasons we should avoid using the heap as much as possible. Given this only applies to numeric digits, I think it would be better to just stack allocate an array of a certain size.
Trying to be forward looking, we can probably get away with a local heap of size 128 bytes, since that covers the maximum character length of Arrow's Decimal256 (76), and sizes up to a power of 2. Anything longer that that can reasonably not be parsed as numeric
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For performance reasons we should avoid using the heap as much as possible. Given this only applies to numeric digits, I think it would be better to just stack allocate an array of a certain size.
Question: The approach of using a stack will not be thread safe. Is this a problem?
Another approach that I was thinking of was to use a do-while loop, verifying if it stopped in tsep. It will complicate the code a little bit, but will be thread safe and won't need dynamic memory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Every thread gets its own stack, so the stack solution is thread safe while the heap is not. Perhaps you are mixing stack/local variables with the concept of static?
Of course we aren't doing any multithreaded parsing here, but that's a great question and thing to consider
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Every thread gets its own stack, so the stack solution is thread safe while the heap is not.
Thanks, I didn't know that.
Perhaps you are mixing stack/local variables with the concept of static?
I first thought that I should make the array a global variable, that's the reason for the confusion.
I created a buffer of size 128 in the stack to remove tsep. With these changes, I removed the malloc call and the memory error.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it necessary to add this? I don't think we should be special-casing behavior for null or the null byte; I expect the former is undefined (since its not a string) and the latter would be handled naturally by the rest of the logic (?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, not necessary. The null byte is already handled below.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| char *endptr = NULL; | |
| char *endptr; |
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a matter of convention need to check errno and "raise" if its set before clearing it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By "raise" you mean printing to stderr?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By "raise" I mean follow whatever exception handling is implemented. In this particular function, it looks like you should set the error variable and return 0 when an exception is encountered
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to give the CPython error handling doc a read, which most of the extensions base their methodology off of:
https://docs.python.org/3/c-api/exceptions.html#exception-handling
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am now resetting errno after handling the overflow error
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose this is unrelated to your PR but why does this function accept int_max and int_min as arguments? Assuming those are actually set to INT64_MAX and INT64_MIN this is a no-op, and potentially waste of cycles if the compiler can't optimize it away
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, it's unnecessary. It's set to INT64_MAX and INT64_MIN.
pandas/pandas/_libs/parsers.pyx
Lines 1930 to 1931 in 066a4f7
| data[i] = str_to_int64(word, INT64_MIN, INT64_MAX, | |
| &error, parser.thousands) |
Should I just check errno or I should also change the function signature?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing the function signature is fine (let's do as a separate PR)
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you removed the const char *p = p_item assignment as a cleanup and not for any type of functionality, but if that's true its inflating the diff. Should move cleanup items like that to a separate PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've made several changes that complicate a lot the diff. I'll put back the const char *p assignment, and also remove the need for some auxiliary functions created.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great - thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's already a PARSER_OUT_OF_MEMORY define in this header - does this provide anything different?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I missed it. Since we will avoid using dynamic memory, I will delete it soon and the memory error won't be applicable.