ch <- bytes.Contains(b.Bytes()[start:end], find)
select {
case <-quit:
quit <- "bye"
return
}
Don't you want a "default:" case in there? This way all your goroutines are
kept alive and waiting for that quit - which only ONE goroutine will get!
Use close(quit) - that will signal all goroutines!
BTW your bytes.Contains won't break mid-execution, so it either executes,
or it haven't even started yet on "quit".
You have to break the problem to smaller chunks and loop on it, checking
the quit channel on each iteration.
Or accept that this few hundred MBs is not big, and forget all the
complexity, just bytes.Contains each part (/core) and write the result into
a make([]bool, core), at the right index,
and at last iterate over this result slice and check whether any found sth.
You'll still need a WaitGroup for waiting all goroutines.
Const V a következőt írta (2022. június 13., hétfő, 1:55:11 UTC+2):
> 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/21c9ae98-3136-4701-bca9-67b39c13bdb4n%40googlegroups.com.
