#high usage of runtime.memmove in top10 (pprof)
38 messages · Page 1 of 1 (latest)
do the buf := before the loop
and use strings.Builder or bytes.Buffer instead of buffer +=
or it will make a lot of unused strings
And you have to improve the strings.Contains
to lower the CPU usage
wdym
yes
it will write the buf again
type Reader interface {
Read(p []byte) (n int, err error)
}
Reader is the interface that wraps the basic Read method....
More documentation omitted
no it won't, it will write from the start of the slice
wait but if the buf contains [0,1,0,1] and it only gets [1,0,0,0] in the next read (one byte of data from remote) the buf wont look like [1,1,0,1]?
it will replace all the data that avaliable (n)
so if your slice is [0 0 0 1], and the data avaliable is [2], then you slice will be [2 0 0 1] or [2 1 2 3] we don't know, the only thing Read can promise to you is correct is buf[:n]
so you have to fix your code
not use buf but buf[:n]
This won't close
But if it's inactive for one day, then it will be mark as stale
you can ping me if you want get help
Note that when it's marked as stale, you can still send messages
yea - so I'd say string concat was the issue
maybe, but reallocation itself doesn't cause memmove afaik
I'll say that 1024 is a little bit low, your computer can handle 1MB really well
But depends on your sender, if you send piece messages, then lower buffer works
It's 128KB, maybe yeah
also I always start with something from 1024 to 4096
the latter is what bufio does
hm what's the point to use readUntil for http requests
looks like XY problem
You should use scanner for http request, it should be read line by line until a empty line
so bufio.Reader is your best choice maybe
func (b *Reader) ReadLine() (line []byte, isPrefix bool, err error)
```
ReadLine is a low-level line-reading primitive. Most callers should use ReadBytes('\n') or ReadString('\n') instead or use a Scanner....
*More documentation omitted*
I'll go sleep now anyways, will check tomorrow