crypto5

17 ms·

121.
by crypto5 13y ago
For memory intensive tests the score is 2-3 there.
122.
by crypto5 13y ago
> -Memory footprint matter to you (and you don't want to pick C) Is there any clear evidence of better memory management in Go comparing to JVM?
123.
by crypto5 13y ago
For me, maintenance of large DBs can be very expensive. Some simple query like select count(*) from where ... can easily cost $10, and mysql will give you it for free.
124.
by crypto5 13y ago
> 6h on the slow servers or 6mins on the best one (which just has a better processor than the others). 60 times differences? What kind of CPUs do you have in slow and fast servers?
125.
by crypto5 13y ago
I think you can import libraries directly from github, google code, bitbucket, launchpad. Does it cover your needs?
126.
by crypto5 13y ago
Just curious: and what is your estimation of salary ranges for Java SWE in Seattle? How many sexy start-ups/companies there(I think not too many). Can diff in salary between Seattle and SF be covered by $500-$1000 savings on apartment rent?
127.
by crypto5 13y ago
I was always curious, why they called this class as Calendar. It's actually date/datetime/time.
128.
by crypto5 13y ago
> The US consumes a lot of resources because it still produces so much of the world's GDP. 80% of US GDP is "services", not a real production.
129.
by crypto5 13y ago
Sadly, no cassandra support yet..
130.
by crypto5 13y ago
It's hidden from me behind client library API(astyanax in my case), I shouldn't know anything about index locality. I just send request(give me records for this index value), and get response and don't care if it's local index or distribute
131.
by crypto5 13y ago
Just curious: did you get any real problem with local indexes? For me it works just fine.
132.
by crypto5 13y ago
This solution doesn't look production solid for linux server. I am not sure about lz4, but gzip in my cassandra experience is significantly reducing performance, Db needs spend too much CPU on compression. Snappy works just fine.
133.
by crypto5 13y ago
page level(not field level) snappy compression
134.
by crypto5 13y ago
So, what's better currently available alternative to GAE in terms of free quota?
135.
by crypto5 13y ago
Do we have any chance to look at round 3 results?
136.
by crypto5 14y ago
One of the things I am missing in postgresql is compressed tables. It's actually big game changer in some cases.
137.
by crypto5 14y ago
Documentation looks quite incomplete( http://golang.org/cmd/gofmt/ ). Will it change all imports and usages of class/method/field? Will it resolve all signature polymorphic calls?
138.
by crypto5 14y ago
So, is it possible to move/rename class/method/field smoothly using those tools? Extract code block to new method?
139.
by crypto5 14y ago
But go ecosystem still doesn't have anything even close to refactoring abilities of Java/C# IDEs. Say, move Java class which is in use in 100s places from one package to another is just few mouse clicks in Eclipse and a lot of pain in case
140.
by crypto5 14y ago
I think if you will write to Cassandra with consistency level ALL, you will get strong consistency. Or you can use write consistency = 1 and read = ALL, or write consistency = Quorum and read consistency = Quorum.
141.
by crypto5 14y ago
> Yeah- that is great as long as you don't care about using 30x times more memory.... > Go vs Scala: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... . There is no such thing on that page. You see 30x times win for g
142.
by crypto5 14y ago
What kind of technology is behind Present? In my understanding it's easy to place all data to DB/FS buffers with any DB engine and get superfast operations.
143.
by crypto5 14y ago
Benchmark will be not so good, but do you have better choice?
144.
by crypto5 14y ago
It can be configured: http://wiki.apache.org/cassandra/Durability One option is to fsync changes before telling client that operation is succeeded.
145.
by crypto5 14y ago
Not exactly. Cassandra writes commit log, and if JVM will crash, cassandra will repair data from that log.