What is the best way to do it?
--
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
This is related of previous discussion but this time about finding
concurrent solution.
I'm posting my solution. Any feedback and suggestions for improvement are
welcome!
I need to write a program that reads STDIN and should output every line
that contains a search word "test" to STDOUT.
T
rk in another thread with a better focus on
concurrent.
On Monday, June 13, 2022 at 9:10:44 AM UTC-7 Brian Candler wrote:
> On Monday, 13 June 2022 at 01:55:11 UTC+2 Const V wrote:
>
>> The way I'm using is "b" is a large buffer - hundreds of MB.
>> I want to
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
gt; go ()
>
> 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
: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 co
I'm implementing the following algorithm - sending result from
bytes.Contains -
true or false to 1) channel directly and 2) via func.
I'm expecting 1)to be faster but actually 2) is faster:
4.99s vs 6.47s
1) via channel:
for i := 0; i < cores; i++ {
start := i * chunksize
end := min(start+
I'm compiling a list of.
Feel free to commend or add.
### Go Code Checklist
keywords: go, code, checklist, style, naming, testing, gofmt, conventions,
exported, identifiers, capital, letter, unexported, lowercase, snake, case,
mixed, Camel, file, names, package, directory, typos, compiler, warni
GB 11.33%
mobiledatabooks.com/biggrep.Benchmark_100MB_End__20charsBigGrepScan__
3.82s
On Sunday, May 8, 2022 at 9:36:34 PM UTC-7 Const V wrote:
> The program is working fine with STDOUT and there is no need of program >
> /dev/null.
>
> I was using the Pipe for the unit tests with _test
I'm performing tests for API using Gin framework.
using a map for storing key-values.
type database map[string]Item
in endpoint handler:
r.POST("/add", func(c *gin.Context) {
There is a code (key) which is already existing:
"code":"ZRT6-72AS-K736-L4AZ"
If I use
GOMAXPROCS=8 CGO_ENABLED=1
I've the following statements:
type database map[string]Item
var dbmux sync.Mutex
r.POST("/adding", func(c *gin.Context) {
dbmux.Lock()
defer dbmux.Unlock()
db[product.UIID] = item
I'm testing it for concurrency
GOMAXPROCS=8 CGO_ENABLED=1 go test -count 100 -
There is an official one in Golang documentation:
Tutorial: Developing a RESTful API with Go and Gin
https://go.dev/doc/tutorial/web-service-gin
I find Gin framework especially good.
What is your feedback?
--
You received this message because you are subscribed to the Google Groups
"golang-nut
r.Buffer is the easiest and battle tested
> solution.
>
> If not, then you have to reimplement the same, with a temp file as a
> buffer: read input, store in file, seeking to the start on each '\n',
> copying the file to STDOUT when "test" is found.
> No
r much lower memory latency, change these considerations?
>> How much slower will a simple Go clone of grep be than the C version
>> which has had decades of optimisation?
>> And how much effort would it take to optimise the Go clone to reach the
>> performance o
reallocating a buffer is not an option, it should be dynamic
On Sunday, May 8, 2022 at 1:26:34 PM UTC-7 Const V wrote:
> Using r.ReadLine() I can successfully read 100 MB line in a string, using
> the following conditional statement which is
> increasing the buffer until '\n&#
xtent does the Apple/Arm system on chip family,
> with their much lower memory latency, change these considerations?
> How much slower will a simple Go clone of grep be than the C version which
> has had decades of optimisation?
> And how much effort would it take to optimise the Go c
what extent does the Apple/Arm system on chip family,
> with their much lower memory latency, change these considerations?
> How much slower will a simple Go clone of grep be than the C version which
> has had decades of optimisation?
> And how much effort would it take to optimise the
The question is will scanner.Scan handle a line of 100s MB?
On Saturday, May 7, 2022 at 2:49:08 PM UTC-7 Amnon wrote:
> How about something like
>
> func grep(pat []byte, r io.Reader, w io.Writer) error {
> scanner := bufio.NewScanner(r)
> for scanner.Scan() {
> if (bytes.Contain
Here is what came up withL
func TestGrep1(t *testing.T) {
cmd := exec.Command("./read.bash")
fmt.Printf("%v\n", cmd)
stdout, err := cmd.StdoutPipe()
if err != nil {
log.Fatal(err)
}
if err := cmd.Start(); err != nil {
log.Fatal(err)
}
fmt.Printf("%v\n", stdout)
find := []byte{'b', 'u', 'f', 'i', '
Now the next question is if I have to handle runes.
On Saturday, May 7, 2022 at 3:31:31 PM UTC-7 kortschak wrote:
> On Sat, 2022-05-07 at 15:18 -0700, Amnon wrote:
> > The other interesting question is what algorithm we use to find the
> > pattern in each line.
> > Generally bytes.Contains uses R
I need to write a program that reads STDIN and should output every line
that contains a search word "test" to STDOUT.
How I can test that considering the problem is a line can be 100s of MB
long (\n is line end) and tens of MB info is passed to it.
--
You received this message because you a
21 matches
Mail list logo
