Added NullUniqueIdentifier struct to work with GUIDs that can be null #635
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
@@ Coverage Diff @@
## master #635 +/- ##
==========================================
- Coverage 71.98% 71.97% -0.02%
==========================================
Files 24 25 +1
Lines 5469 5491 +22
==========================================
+ Hits 3937 3952 +15
- Misses 1309 1314 +5
- Partials 223 225 +2
Continue to review full report at Codecov.
|
denisenkom
reviewed
Apr 11, 2021
| } | ||
|
|
||
| err := nui.UniqueIdentifier.Scan(v) | ||
| if err != nil { |
There was a problem hiding this comment.
Converting any possible scan error into a Null value doesn't seem right to me, error checking should be more specific
ninjadq
pushed a commit
to ninjadq/go-mssqldb
that referenced
this pull request
May 28, 2024
Optimize In performance by reducing allocations for common queries
ninjadq
pushed a commit
to ninjadq/go-mssqldb
that referenced
this pull request
May 28, 2024
The changes in denisenkom#635 changed the some of the output types of In to pointers. This takes less time but it also changed the types in the output of In in a way that I think is more aggressive than I would have preferred. I'm also not 100% convinced that using pointers to types like `int` and `string` would provide an overall performance benefit when you factor in GC. Despite that, timings did get worse: pre-change: ``` BenchmarkIn-4 3136129 376 ns/op 272 B/op 4 allocs/op BenchmarkIn1k-4 171588 6602 ns/op 19488 B/op 3 allocs/op BenchmarkIn1kInt-4 157549 7502 ns/op 19488 B/op 3 allocs/op BenchmarkIn1kString-4 155502 7604 ns/op 19488 B/op 3 allocs/op ``` post-change: ``` BenchmarkIn-4 3007132 396 ns/op 272 B/op 4 allocs/op BenchmarkIn1k-4 175978 6768 ns/op 19488 B/op 3 allocs/op BenchmarkIn1kInt-4 120422 10125 ns/op 19488 B/op 3 allocs/op BenchmarkIn1kString-4 108813 10755 ns/op 19488 B/op 3 allocs/op ``` I'd prefer to keep `[]int{..}` producing ints instead of `*int` even if it means losing ~25% of perf on these special cased functions.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm working with the excecution of stored procedures, if the execution generates an transaction the answer will include a GUID, if it do not generates an transaction it does not mean there is an error, so I can or can't receive an unique identifier, thats why I think would be nice to include this data type in this proyect.