All valid questions.
Still my original question remains - the timing I've got is inuntitive.
On Sunday, June 12, 2022 at 9:49:50 PM UTC-7 Tamás Gulácsi wrote:
> 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/eb5e81d9-4aa7-428c-97b4-7c628bb2ca36n%40googlegroups.com.
