You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I encountered this bug while doing type checks, not with actual data, but then again it wouldn't trigger an error so it may have just not been noticed.
I recently replaced the regex-based substitution to escape and unescape TSDB strings with simple str.replace() calls, which were about 3-4 time faster. This works well enough for escaping, but for unescaping it causes issues because of the multiple calls. Specifically, an escaped \ followed by a regular s or n would look like an escaped \s or \n:
\\s replace \\ with \
\s replace \s with @
@
Switching the order of the replaces wouldn't help, because \\s would become \@ instead of \s. Instead, unescaping needs to return to some sequential low-level parser. Maybe a simple for-loop with if-statements will not be as slow as re.sub().
The text was updated successfully, but these errors were encountered:
I encountered this bug while doing type checks, not with actual data, but then again it wouldn't trigger an error so it may have just not been noticed.
I recently replaced the regex-based substitution to escape and unescape TSDB strings with simple
str.replace()
calls, which were about 3-4 time faster. This works well enough for escaping, but for unescaping it causes issues because of the multiple calls. Specifically, an escaped\
followed by a regulars
orn
would look like an escaped\s
or\n
:Switching the order of the replaces wouldn't help, because
\\s
would become\@
instead of\s
. Instead, unescaping needs to return to some sequential low-level parser. Maybe a simple for-loop with if-statements will not be as slow asre.sub()
.The text was updated successfully, but these errors were encountered: