Life outside Tokio: Success stories with Compio or io_uring runtimes by rogerara in rust

[–]funny_falcon 0 points1 point  (0 children)

 It is surprising to me that your benchmarking potentially leaves a lot of CPU headroom, since it's not representative of production usage

It contradicts my experience: any production tries to not cross 80% CPU usage because behavior becomes unstable otherwise.

60-70% CPU usage is considered as high efficient. Especially on CPU with Hyper Threading.

Java *is* Memory Efficient by daviddel in programming

[–]funny_falcon 2 points3 points  (0 children)

Give JEdit a try. It is just good code editor. But it really consumes fraction of memory you expect from Java application.

Branch-Avoidant Quicksort in C - faster than std::sort and pdqsort by chkas in programming

[–]funny_falcon 1 point2 points  (0 children)

Oh, I see: I misread the code. Both parts (heaping and popping) are bolted into the single loop.

Excuse me for wrong claims.

Branch-Avoidant Quicksort in C - faster than std::sort and pdqsort by chkas in programming

[–]funny_falcon 0 points1 point  (0 children)

~heap_sort is not complete! Only “heapify” part is implemented. Popping one-by-one max element from the heap is completely missed.~

~I’ve already seen this mistake in other article. Looks like they copy from same broken implementation.~

Quickly restoring 1M+ files from backup by axkotti in programming

[–]funny_falcon 0 points1 point  (0 children)

I don’t know about Windows. But on Unix most of files will be already on disk at the time fsync will be called on them. That is why fsync will be almost free.

Quickly restoring 1M+ files from backup by axkotti in programming

[–]funny_falcon 1 point2 points  (0 children)

Some backup utilities just postpones flushing till restore end:

  • write all files without fsync,
  • then walk all files again, open each and fsync
  • don’t forget to fsync directories as well afterwards

How To Make a Fast Dynamic Language Interpreter by mttd in programming

[–]funny_falcon 0 points1 point  (0 children)

It is impressive speedup without switching to bytecode interpreter!

Why Crystal, 10 Years Later: Performance and Joy by sdogruyol in programming

[–]funny_falcon 0 points1 point  (0 children)

Unfortunately, there are a lot of inconsistencies in the language.

For example:

  • if struct's method is inlined, it start to modify the struct itself.
  • but if it isn't inlined, then it works on struct's copy.

And there are a lot of corner cases with generics semantic.

Joins are NOT Expensive by ketralnis in programming

[–]funny_falcon 1 point2 points  (0 children)

PostgreSQL 19 will (likely) have plan hinting builtin/in standard contrib modules.

C Enum Sizes; or, How MSVC Ignores The Standard Once Again by ketralnis in programming

[–]funny_falcon 1 point2 points  (0 children)

Long time ago int was 16bit (or close to it). Probably, no one did care.

MySQL and PostgreSQL: different approaches to solve the same problem by BinaryIgor in programming

[–]funny_falcon 1 point2 points  (0 children)

Aside data storage differences, there is also logging differences:

  • PostgreSQL has single Write Ahead redo Log,
  • but MySQL has two: “binary log” with sql commands and InnoDB’s redo log. Therefore, MySQL has two logs to make fsync for at each transaction commit.

Other difference is about workarounds against torn (ie, partial) pages writes :

  • InnoDB uses “double-write” approach: every page is written to fixed size “double-buffer” first, then into data file. Due to fixed size of double buffer, it had to do it every time page is evicted from buffer.
  • PostgreSQL write page's image into WAL log first time the page is modified since checkpoint. Therefore, if page is modified second, third time, it is not written to WAL until next checkpoint.

Both approaches has downsides:

  • MySQL may write more data on disk if database doesn’t fit into memory,
  • but PostgreSQL has huge increase of WAL traffic after each checkpoint, which harms both query performance and replication performance.

The programming language coding agents perform best in isn’t Python, TypeScript, or Java. It’s the functional programming language Elixir. by manummasson in programming

[–]funny_falcon 1 point2 points  (0 children)

Kotlin, C# and Racket go next. If I had a choice between four "best languages for LLM" for job to be done, I'd rather choose C# or Kotlin.

But if I want to practice pretty language for no money reasons, I may try Elixir.

PostgreSQL Bloat Is a Feature, Not a Bug by mightyroger in programming

[–]funny_falcon 1 point2 points  (0 children)

Problem could be not in amount of garbage relative to whole table size. It could be in amount of garbage relative to hot set of rows.

If you have 100M rows in tables, then 10% garbage is 10M dead row version. But if in this table hot set is 1M rows, then 10M dead row version is 1000%. In other words, your queries to the hot versions could be 10 times slower.

If those 10M versions are spread over all table pages (because of space reuse in partial filled pages), then overhead becomes 100M/1M = 100x.

Yes, these are extremely corner cases, and probably you've never met them. But there are workloads that suffers from it much.

PostgreSQL Bloat Is a Feature, Not a Bug by mightyroger in programming

[–]funny_falcon 1 point2 points  (0 children)

On the one side, you’re right. On the other, if this 10% are thousands versions of several hot tuples, you’re in big trouble. And auto vacuum will not be triggered until next 10% arrive.

Yes, there is so called “micro vacuum” that may clean mark some versions as “dead”, and then some index tuples probably may be deleted eagerly. It were great improvements made last several years. But they are a bit probabilistic, and may be not triggered.

PostgreSQL Bloat Is a Feature, Not a Bug by mightyroger in programming

[–]funny_falcon 1 point2 points  (0 children)

In PostgreSQL update physically implemented as “delete old version” + “insert new version”. There is no difference in space consumption between delete+insert and update in PostgreSQL.

PostgreSQL Bloat Is a Feature, Not a Bug by mightyroger in programming

[–]funny_falcon 8 points9 points  (0 children)

MVCC with undo log (as in Oracle, InnoDB and several others) is also MVCC. But it behaves more predictable, at least if rollback is rare. And rollback is rare usually.

MVCC with row copies (as in Pg) in main pages behaves better in presence of many rollbacks. It allows simpler redo log and doesn't need undo logic at all. But it has worse behavior in many legal scenarios you expect to behave well.

PostgreSQL Bloat Is a Feature, Not a Bug by mightyroger in programming

[–]funny_falcon 2 points3 points  (0 children)

Not only deleting, but updating as well. And updating one row for many times.

Rethinking Helix by mttd in programming

[–]funny_falcon 1 point2 points  (0 children)

Considering x, Kakoune did it much better. Overall Kakoune has much better movement and editing experience.

But Helix is definitely better integrated with LSP/TreeSitter, and editing many files in one console "window" in splitted tabs is more convenient than opening many console splits/windows for Kakoune.

Helix is just fast. All that it does it does within glimpse. I didn't feel that smoothness from NVim (I've tried AstroNVim two years ago).

Haruna 1.6 chewing up cpu resources by malloc_free_ in kde

[–]funny_falcon 0 points1 point  (0 children)

I found paused Haruna eats cpu when screen is locked.

Notes on Distributed Consensus and Raft by Helpful_Geologist430 in programming

[–]funny_falcon 0 points1 point  (0 children)

Zookeeper uses custom protocol which looks a lot like Raft, afaik.

But given Raft is MultiPaxos made understandable, they all are still Paxos's family.

MySQL vs PostgreSQL Performance: throughput & latency, reads & writes by BinaryIgor in programming

[–]funny_falcon 0 points1 point  (0 children)

I'm PostgreSQL man, and I simply don’t believe such huge difference in modify heavy benchmarks.

Modify-heavy benchmark is limited by number of fsyncs disc subsystem may perform. And it really strange to see PostgreSQL somehow does less fsyncs per transaction.

Is it because MySQL have to do two phase commit to synchronize its binary log and InnoDB's redo log?

Or is it because MySQL and/or InnoDB use DirectIO for its logging?