Re: [go-nuts] govulncheck

2024-03-10 Thread Colton Freeman 
Disregard. Figured out the tool (a little better). Would still love to chat
with some that has in depth experience with it though.

On Fri, Mar 8, 2024, 1:36 PM Colton Freeman 
wrote:

> good day all,
> i am not a developer and have just recently stumbled upon the
> `govulncheck` tool from golang.
> i am curious how accurate this tool is and if it should be used in a scan
> report for vulnerabilities?
> do we need to run this on the main.go and reference the go.mod file in the
> project?
> another question would be about the go.mod. does this tool only scan go
> packages `gopkg.in/yaml.v3 v3.0.1` or is it anything listed in the go.mod
> `github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v1.2.0`
>
> if you need more info or have questions please feel free to ask.
>
> W/r
> Colton.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/K3PZCxo_XvY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/2fca01b6-5bc8-49ee-bb21-eba166063d35n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKjFZFiqW6r%3D2CobPdiJVKgOKCG_9o5A0KEGwNvc4KCgDvAKzA%40mail.gmail.com.

[go-nuts] Why is more memory being used when encoding a slice of structs with smaller length

2024-03-10 Thread Kwaku Biney 


When using `binary.Write` for encoding a slice of structs, I encountered 
some weird behaviour where memory allocations in a particular path was more 
than I expected.

I wrote some benchmarks in the standard library's encoding/binary package 
to demonstrate this.

func BenchmarkWriteSlice1000Structs(b *testing.B) { slice := make([]Struct, 
1000) buf := new(bytes.Buffer) var w io.Writer = buf 
b.SetBytes(int64(Size(slice))) b.ResetTimer() for i := 0; i < b.N; i++ { 
buf.Reset() Write(w, BigEndian, slice) } b.StopTimer() } func 
BenchmarkWriteSlice10Structs(b *testing.B) { slice := make([]Struct, 10) 
buf := new(bytes.Buffer) var w io.Writer = buf 
b.SetBytes(int64(Size(slice))) b.ResetTimer() for i := 0; i < b.N; i++ { 
buf.Reset() Write(w, BigEndian, slice) } b.StopTimer() }

   - Encoding a slice with 1000 struct elements

root@ubuntu-s-2vcpu-2gb-fra1-01:~/go/src/encoding/binary# ../../../bin/go 
test -run='^$' -memprofile memprofile.out -benchmem -bench 
BenchmarkWriteSlice1000Structs -count=10 
root@ubuntu-s-2vcpu-2gb-fra1-01:~/go/src/encoding/binary# ../../../bin/go 
tool pprof memprofile.out File: binary.test Type: alloc_space Time: Mar 9, 
2024 at 3:27pm (UTC) Entering interactive mode (type "help" for commands, 
"o" for options) (pprof) top Showing nodes accounting for 1305.40MB, 99.84% 
of 1307.48MB total Dropped 8 nodes (cum <= 6.54MB) flat flat% sum% cum cum% 
1302.13MB 99.59% 99.59% 1304.21MB 99.75% encoding/binary.Write 3.27MB 0.25% 
99.84% 1307.48MB 100% encoding/binary.BenchmarkWriteSlice1000Structs 0 0% 
99.84% 1305.31MB 99.83% testing.(*B).launch 0 0% 99.84% 1307.48MB 100% 
testing.(*B).runN


   - Encoding a slice with 10 struct elements

root@ubuntu-s-2vcpu-2gb-fra1-01:~/go/src/encoding/binary# > ../../../bin/go 
test -run='^$' -memprofile memprofile.out -benchmem -bench 
BenchmarkWriteSlice10Structs -count=10 
root@ubuntu-s-2vcpu-2gb-fra1-01:~/go/src/encoding/binary# ../../../bin/go 
tool pprof memprofile.out warning: GOPATH set to GOROOT (/root/go) has no 
effect File: binary.test Type: alloc_space Time: Mar 9, 2024 at 4:24pm 
(UTC) Entering interactive mode (type "help" for commands, "o" for options) 
(pprof) top Showing nodes accounting for 905.58MB, 100% of 905.58MB total 
flat flat% sum% cum cum% 792.58MB 87.52% 87.52% 905.58MB 100% 
encoding/binary.Write 113MB 12.48% 100% 113MB 12.48% 
reflect.(*structType).Field 0 0% 100% 905.58MB 100% 
encoding/binary.BenchmarkWriteSlice10Structs 0 0% 100% 113MB 12.48% 
encoding/binary.dataSize 0 0% 100% 113MB 12.48% encoding/binary.sizeof 0 0% 
100% 113MB 12.48% reflect.(*rtype).Field 0 0% 100% 905.58MB 100% 
testing.(*B).launch 0 0% 100% 905.58MB 100% testing.(*B).runN (pprof) 

Per the benchmarks, there is a rise in total memory allocated incurred at `
reflect.(*structType).Field` when encoding a slice of 10 struct elements 
compared to a slice of 1000 struct elements. I expected to see the memory 
incurred to be at worst, the same if not less when encoding a slice of 
structs with lesser length. I draw my conclusion from here since we are 
calling sizeof on the same struct type regardless of the length of the 
slice. 
[](https://github.com/golang/go/blob/74726defe99bb1e19cee35e27db697085f06fda1/src/encoding/binary/binary.go#L483)

Also, looking at the primary source of the allocations, per the line below, 
since we are working with the same struct type, I expect the memory used 
here to be the same regardless since both benchmarks are working with the 
same struct type and hence have the same fields.

[](https://github.com/golang/go/blob/74726defe99bb1e19cee35e27db697085f06fda1/src/reflect/type.go#L1061)

Is this change because of memory constraints when I scale to a 1000 
structs or am I just missing something obvious?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/68d5cbcf-ac74-4d68-b186-4014cb370162n%40googlegroups.com.

Re: [go-nuts] How To Reduce Json Marshalling Time

2024-03-10 Thread Robert Engels 
Apologies.On Mar 9, 2024, at 1:16 PM, Ian Lance Taylor  wrote:This thread has gotten heated.  I think it's time to move on to different topics and give this discussion a rest.  Thanks.Ian



-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXbXBEMCpgPH_piQH0-jZoC_Lok94Oo9%2Bbe2fDBnaWgNA%40mail.gmail.com.




-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/26C7753E-CEF8-42F9-9ED6-68513CC0BF5A%40ix.netcom.com.