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

Speed up #10

Open
whilp opened this issue Jan 14, 2016 · 0 comments
Open

Speed up #10

whilp opened this issue Jan 14, 2016 · 0 comments

Comments

@whilp
Copy link
Owner

whilp commented Jan 14, 2016

Per @anachronistic:

so - i did a couple of benchmarks on the lib and found differing speeds + heap allocations depending on the incoming string
and i believe that it's possible to 1) normalize the speed to within reason (i.e. longer strings will naturally take a bit longer to parse), 2) normalize the allocations (i believe you can produce a 0 allocation lib if you write the parser yourself)
i did a shit proof of concept and for local paths i had it down to 150ns / 0 allocations by having a Parse method that accepts a pointer to a net.URLstructure ... ex func Parse(url string, handle *net.URL) error { ... }
that was leaning mostly on strings.Index which reports first appearance of a pattern, so ex. colon := strings.Index(url, ":") ... slash := strings.Index(url, "/") ... return colon == -1 || (slash & slash > colon)
so file:///whatever and /foo/bar/whatever returned true very quickly
it gets a touch more complicated from there, but yeah: that's my challenge to you ... normalized speed (for some reasonable definition of normalized compared to string length) and 0 allocations (or at most 1 if you don't like the C-style of passing in the structure)

@whilp whilp self-assigned this Jan 14, 2016
@whilp whilp removed their assignment Aug 17, 2019
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

No branches or pull requests

1 participant