> them sequentially? It seems that there is somewhere else a bottleneck...
>
> Am Sonntag, 16. September 2018 14:08:50 UTC+2 schrieb Thomas Solignac:
>>
>> Hello,
>>
>> I have a loading step, where I have something like 60 files to read and
>> process, as fast as pos
; You might also check out my blog post on constructing parallel goroutine
> pipelines; the Digesting a Tree section discusses parallel file I/O:
> http://blog.golang.org/pipelines
>
> S
>
> On Sun, Sep 16, 2018 at 8:08 AM Thomas Solignac > wrote:
>
>> Hello,
>>
Hello,
I have a loading step, where I have something like 60 files to read and
process, as fast as possible.
I tried loading with goroutines and without, and I get substantially the
same process time (38s).
*What is the more idiomatic ? Is Golang designed for concurrent files I/O ?*
Note : One
That's great ! Thank you !
Le samedi 12 août 2017 14:51:14 UTC+2, Mandolyte a écrit :
>
> The experience reports at
> https://github.com/golang/go/wiki/ExperienceReports include a reference
> to an article on experience and recommendations for Go2 from CMU. Good read!
>
> Direct link:
> http://w
m individually.
>
> On Friday, January 20, 2017 at 3:54:21 AM UTC-6, Thomas Solignac wrote:
>>
>>
>> Thank you both for your answers.
>>
>> It's true that there is a convention for JSON streaming in which one each
>> json message is followed by a
Thank you both for your answers.
It's true that there is a convention for JSON streaming in which one each
json message is followed by a '\n'.
There is + and - for this convention.
*+ :*
-> I can detect bad JSON
*- :*
-> The most important : It's a little more painful for final user. It's
al
Let's say you make a sudoku solver, as fast as possible.
You have a multicore computer.
If the disk read or parsing is slow, you are going to prepare sudoku files
in 3 goroutines, let's say.
And the 4th thread (the main thread, let's say) will solve them.
How the main thread can get sudoku to so
n't know where it ends, and it
> can't proceed to the next one.
>
> Closing the connection is probably appropriate when the other side sends
> something that cannot be decoded.
>
> //jb
>
> > On 19 Jan 2017, at 18:22, Thomas Solignac > wrote:
> >
&
Hello,
I build a service receiving Json from websocket.
I use json decode.
I want my service to be robust !
*var tmp interface{}*
*err = this.reader.Decode(&tmp)*
My problem is :
When I got some error here, I came to infinite loop, because the decoder
doesn't go forward.
It seems that it is t
It seems that the function follows accumulates:
Runtime / pprof.writeHeap + 0x29b6
This is what is observed in /heap.
The number of it increases but never decreases.
Le mercredi 4 janvier 2017 07:52:25 UTC+1, Dave Cheney a écrit :
>
> Can you provide a runnable sample which shows the problem?
>
>
Hello,
Thank you, I was going to launch the same subject.
I see the same thing.
When I access to /debug/pprof, there is the "heap". And I got the detail in
"debug/pprof/heap?debug=1"
I get more heap when I refresh the /heap page. And it never decrease.
Thank you for your help
Le mercredi 4 j
11 matches
Mail list logo