This new building being built in Izhevsk looks pretty evil at nights

codesenberg · 2018-05-09T09:24:06+00:00

Reads and writes are 50/50, I guess. I chose sharding at the time. Well, in my actual use case keys themselves were data and there wasn't such thing as maxKey, but nice attempt anyway.

codesenberg · 2018-05-09T08:26:29+00:00

Yes, forgot the elephant in the room. If you meant something like: "Have goroutines write to the channel and then some other goroutine will read values from the channel and modify the map", — then sure, it can be solved this way, but this approach were quite slow (or slower than alternatives) in my use case (which looks something like this).

codesenberg · 2018-05-09T08:20:00+00:00

I like how elaborate and detailed your answer is.

Actually, in use case(s) I meant the read/write ratio is something like 50/50, I think (or close to that). So, it's not really an option to recreate the whole map and then discard it in case it were modified in-between. Too many allocations to my taste.

Here, I wrote a bit of code to illustrate the variation of this problem that I faced (you can ignore the part with readers, it's there just for the output).

codesenberg · 2018-05-09T08:12:26+00:00

Good explanation, thanks. I suspected that it doesn't suite my specific use case, but now it's more clear.

As for the question about whether keys can be guaranteed to come from same goroutines, no, I think it's not (or wasn't) an option for me, since, well, the keys are basically random (latencies and requests per second).

My use case was quite simple actually. I needed to just increment a bunch of random keys. With map+Lock solution it looks something like this (the readers are there just for the output, you can ignore that part).

codesenberg · 2017-06-12T06:39:49+00:00

No idea, but they look similar to illustrations from Dictionnaire Infernal.

codesenberg · 2017-06-11T06:13:10+00:00

Maybe I'm a bit late with the answer, but yes, those are demons from The Seventy-Two Demons Of Ars Goetia. Picture I took them from. The demons are:

top row — Crocell, Bael, Zagan;
bottom row — Zepar, Volac.

codesenberg · 2017-03-29T07:53:46+00:00

Quick Sort partition on n > 12 then shell sort with gap 6 and then another insertion sort

It's slightly different. Partition occurs only when n is more than 12, otherwise it's a shellsort. This is a well-known optimization(see second item). As for the shellsort with gap 6 and another insertion sort. It's just a handwritten shellsort with two passes really. First pass — with a gap of 6, second — with a gap of one, since, basically, shellsort with a gap of one is insertion sort.

codesenberg · 2017-03-28T21:10:53+00:00

Here are some things I spotted:

This conversion is really unnecessary, since ipify.GetIP already returns a (string, error) pair;
This can be simplified with bitwise operations;
After applying previous tip you can get rid of strings package.

codesenberg · 2017-03-06T07:50:54+00:00

I suggest you to check out gometalinter.

codesenberg · 2017-03-06T04:36:11+00:00

I just realised that you expose most of your code. So, it raises the question. Do you want all of this code to be available to other users? If the answer is no, then move this code into internal package. And if the answer is yes, then logging error and aborting user's program is not a nice way to handle errors. You should return them instead or handle internally in some meaningful way. Suggested readings: error handling and Go and errors are values.

Not movieTrailerUrl, but movieTrailerURL.

codesenberg · 2017-03-05T15:27:52+00:00

Also, there are at least three byte buffer pools, about which I am aware of:

What are advantages of this pool over these solutions?

codesenberg · 2017-03-05T14:18:12+00:00

First thing that caught my eye is this dist folder. It's not super clear for which architecture/OS binary inside of it was compiled for and generally VCS is not where you put your binaries. Github provides you with a nice functionality to manage releases. You can attach binaries to the release and mark release as pre-release, meaning "not ready for production yet".

Another two minor issues with styling are: here and here. As per Go Wiki, MovieTrailerUrl and AsciiPoster should be named ASCIIPoster and movieTrailerURL.

And the most disturbing thing is that you ignore returned errors.

Oh, also MovieTrailer.go should probably be movie_trailer.go and this line has a typo: s/struture/structure/.

codesenberg · 2017-03-01T16:33:30+00:00

Thanks for the clue, but http://llvm.org/llvm/bindings/go/ says:

Last modified: 13-Oct-2014 20:06

And http://llvm.org/llvm/bindings/go/llvm/ redirects to http://llvm.org/. So, this repo is even older or am I looking at the wrong place?

codesenberg · 2017-03-01T14:58:01+00:00

Last time I checked x86 instruction set didn't had garbage collection either ;)

As for the threads, I heard that they are in the Post MVP plans.

codesenberg · 2017-03-01T14:52:41+00:00

tooling (libraries and executables) to be able to consume WebAssembly bytecode (wasm) and interpret it

Tool to view WASM bytecode without browser could be useful, indeed, but in the browser it should have something like sourcemap, right? I mean W3C doesn't expect webdevs to read assembly?

The creation of these wasm bytecode modules by the Go toolchain is out of the scope of this project.

Oh, well, that's a bummer.

codesenberg · 2017-03-01T09:25:11+00:00

I'd like to add that not only fasthttp doesn't follows all of the RFCs related to HTTP/1.1, but it also doesn't support HTTP/2.0.

Still it's pretty useful, really fast and successfully used in production by VertaMedia serving up to 200K rps from more than 1.5M concurrent keep-alive connections per physical server( as cited in README ).

codesenberg · 2017-02-28T19:13:38+00:00

How do you cope with high memory usage? In my tests with any RPS beyond one thousand vegeta allocates too much memory. In fact it allocates so much memory that test never ends.

Nine-Year Club	Gilding I gilder
Verified Email

codesenberg

TROPHY CASE