🐛 bug: Case sensitivity for parameters in GetRouteURL

[wangjq4214]

Please provide enough information so that others can review your pull request:

Try to fix case sensitivity for parameters in GetRouteURL.

Explain the details for making this change. What existing problem does the pull request solve?

close #1907

Commit formatting

Use emojis on commit messages so it provides an easy way of identifying the purpose or intention of a commit. Check out the emoji cheatsheet here: https://gitmoji.carloscuesta.me/

[ReneWerner87]

• before the merge I will check the performance

[wangjq4214]

The EqualFold took a lot of time, and according to my Beckmark data, its performance dropped by 50% with a lot of overhead.

A better way to solve this problem may be needed.

[ReneWerner87]

yes I have also noticed, only I can not think of anything better right now

so already, only unfortunately with much overhead
you could keep a list where the parameter names are already uppercase and make the key for the check uppercase before the pass through
but that is pretty overhead

[wangjq4214]

yes I have also noticed, only I can not think of anything better right now

so already, only unfortunately with much overhead you could keep a list where the parameter names are already uppercase and make the key for the check uppercase before the pass through but that is pretty overhead

Do you mean that when calling Param I should check if the key contains uppercase letters? If it contains uppercase letters then should I use the already uppercase list to match param?

I think if it is as I understand it, if the list only contains the path param name defined in the user uri then it is still case sensitive and if the list contains all possible combinations then is the memory overhead higher.

If I don't understand it correctly, can you explain it in more detail?

[ReneWerner87]

Yes you have misunderstood

One way to speed it up would be at the beginning when the route is registered and the parameter names are extracted, create a list with them where they are already all uppercase and then use this list when comparing them

Before of course convert the parameter string which is used in the method(ctx.Params) to uppercase, after that you can test without EqualFold with normal string comparison.

[ReneWerner87]

But the effort is not compared to the benefit

[ReneWerner87]

https://github.com/gofiber/fiber/blob/master/router.go#L263
Normally we only need the params from the prettyied route

[wangjq4214]

But the effort is not compared to the benefit

I agree with you, I'll go back and try it after I basically finish the testing work and documentation for the client refactor this weekend.

[wangjq4214]

Yes you have misunderstood

One way to speed it up would be at the beginning when the route is registered and the parameter names are extracted, create a list with them where they are already all uppercase and then use this list when comparing them

Before of course convert the parameter string which is used in the method(ctx.Params) to uppercase, after that you can test without EqualFold with normal string comparison.

@ReneWerner87 There is still a 30% drop in performance and additional memory and time overhead is introduced during route registration.

[ReneWerner87]

Ok

[ReneWerner87]

I think the last stand is okay. Will merge it in a few hours.