The way I'm using is "b" is a large buffer - hundreds of MB.
I want to stop processing after the string is found using "quit".
for i := 0; i < cores; i++ {
go func(start, end, i int, quit chan string) {
ch <- bytes.Contains(b.Bytes()[start:end], find)
select {
case <-quit:
quit <- "bye"
return
}
}(start, end, i, quit)
}
for i := 0; i < cores; i++ {
if <-ch { // the result from bytes.Contains is true so I want to
stop processing the other routines.
quit <- "quit"
}
}
the whole point was the question is why if I use
BytesContainsCh1(b.Bytes(), start, end, find, ch)
the processing is faster: 4.99s
rather using
ch <- bytes.Contains(b.Bytes()[start:end], find)
6.47s
which takes longer.
The logic says it should be otherwise because BytesContainsCh1 is a
function call and it should be slower.
On Sunday, June 12, 2022 at 2:11:57 PM UTC-7 Brian Candler wrote:
> No: I'm suggesting exactly what I wrote. Starting a goroutine looks like
> this:
>
> go <function>(<args>)
>
> It doesn't have to be an anonymous function, it can be a "real" function.
> Hence this is perfectly valid:
>
> go BytesContainsCh1(b.Bytes(), start, end, find, ch)
>
> On Sunday, 12 June 2022 at 18:17:23 UTC+2 Const V wrote:
>
>> I already have a go routine on the anonymous function:
>> go func(start, end, i int, quit chan string) {
>>
>> You are suggesting doing this?
>> go func(start, end, i int, quit chan string) {
>> go BytesContainsCh1(b.Bytes(), start, end, find, ch)
>> }(start, end, i, quit)
>>
>> On Sunday, June 12, 2022 at 2:54:51 AM UTC-7 Brian Candler wrote:
>>
>>> On Sunday, 12 June 2022 at 09:16:30 UTC+1 Const V wrote:
>>>
>>>> go func(start, end, i int, quit chan string) {
>>>> BytesContainsCh1(b.Bytes(), start, end, find, ch)
>>>> }(start, end, i, quit)
>>>>
>>>
>>> I note that this could be further simplified to:
>>>
>>> go BytesContainsCh1(b.Bytes(), start, end, find, ch)
>>>
>>> Maybe the compiler does this optimisation automatically. Does it make
>>> any difference to your timings?
>>>
>>> If you want to understand the difference you might need to look at the
>>> assembly language generated. See what happens with the number of stack
>>> frames allocated, whether the unused argument 'i' is elided in one of the
>>> cases, and so on.
>>>
>>>>
--
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/14f04ab4-ac20-4e95-b2e4-30951cb7c904n%40googlegroups.com.
