Skip to content
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

Added Multi-Replacement proc for strings #6193

Merged
merged 7 commits into from
Aug 7, 2017

Conversation

fredrikhr
Copy link
Contributor

No description provided.

To prevent endless replacement recursion, replacements cannot overlap.

Earlier replacements in the argument list are preferred over later overlapping replacements.
@cheatfate
Copy link
Member

I dont think word optimized can be used for linear search and replacement with complexity len(tuple)*O(n).

@fredrikhr
Copy link
Contributor Author

@cheatfate optimized in regards to memory allocations... calling replace multiple times instead is worse!

@cheatfate
Copy link
Member

@couven92 if you think add procedure don't do memory allocations, then i want to disappoint you, you are wrong.

@fredrikhr
Copy link
Contributor Author

@cheatfate even if I preallocate like I do in the beginning of the proc?

@cheatfate
Copy link
Member

You allocate one more copy of string in result, what if replacement values much more in size then replacement markers?

@cheatfate
Copy link
Member

Of course if you replace 'a' with 'b' there will be no additional allocations, but what if you replace 'a' with 'aaaaaaaaaaaaa'?

@fredrikhr
Copy link
Contributor Author

yeah, I know... but nothing much we can do about that... But I agree that the documentation comment can be misleading... Any suggestions?

If you have a more optimized version in mind, I'd be happy to hear about it as well :)

## The order of the replacements does matter. Earlier replacements are preferred over later
## replacements in the argument list.
result = newStringOfCap(s.len)
var charsRead = 0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

name 'charsRead' 'i' instead.

result = newStringOfCap(s.len)
var charsRead = 0
while charsRead < s.len:
var noReplacement = true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use a 'block label' + 'break label' here instead of the bool 'noReplacement' flag.

@cheatfate
Copy link
Member

cheatfate commented Aug 6, 2017

There still many ways to improve your code, for example unrolling loop.
https://chadaustin.me/2017/05/writing-a-really-really-fast-json-parser/

Then you can call it optimized, but now it is not optimized... its just simple linear find & replace.

@fredrikhr
Copy link
Contributor Author

Okay @cheatfate I have changed optimized to specialized and added a little more explaination. Is this now more to your liking?

@Araq thanks for the review, have done as you asked. YES! Another case where I can use the block statement! I really love those! :)

@Araq
Copy link
Member

Araq commented Aug 7, 2017

Optimize it further:

var fastChk: set[char] = {}
for r in replacements: incl(fastChk, r[0][0])
...
  # assume most chars are not candidates for any replacement operation:
  if s[i] in fastChk:
    ...

Assume most chars in s are not candidates for any replacement operation
@fredrikhr
Copy link
Contributor Author

@Araq like this?

var i = 0
while i < s.len:
block sIteration:
var fastChk: set[char] = {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to move 'fastChk' construction out of the 'while' loop.

while i < s.len:
block sIteration:
var fastChk: set[char] = {}
for tup in replacements: fastChk.incl(tup[0][0]) # Include first character of all replcaments
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This includes this 'for' loop too, of course.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah! right of course! :P

My brain has gone on holiday it seems!

@Araq Araq merged commit 37a615a into nim-lang:devel Aug 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants