Show HN: DoubleMemory – more efficient local-first read-it-later app (doublememory.com)

Most Java file processing solutions either involve a lot of boilerplate or don’t handle concurrency, backpressure, or metrics well out of the box. I needed something fast, clean, and production-friendly — so I built this.

Key features:

Multi-threaded line/batch processing using a configurable thread pool

Producer/consumer model with built-in backpressure

Buffered, asynchronous writing with optional auto-flush

Live metrics: memory usage, throughput, thread times, queue stats

Simple builder API — minimal setup to get going

Output metrics to JSON, CSV, or human-readable format

Use cases:

Large CSV or log file parsing

ETL pre-processing

Line-by-line filtering and transformation

Batch preparation before ingestion

I’d really appreciate your feedback — feature ideas, performance improvements, critiques, or whether this solves a real problem for others. Thanks for checking it out!

Comments (40)

Calzifer · 4h ago

        for(int i=0;i<10000; ++i){

            // do nothing just compute hash again and again.
            hash = str.hashCode();
        }

https://github.com/MayankPratap/Samchika/blob/ebf45acad1963d...

"do nothing" is correct, "again and again" not so much. Java caches the hash code for Strings and since the JIT knows that (at least in recent version[1]) it might even remove this loop entirely.

[1] https://news.ycombinator.com/item?id=43854337

hyperpape · 3h ago

Even in older versions, if the compiler can see that there are no side-effects, it is free to remove the loop and simply return the value from the first iteration.

I'm actually pretty curious to see what this method does on versions that don't have the optimization to treat hashCodes as quasi-final.

A quick test using Java 17 shows it's not being optimized away _completely_, but it's taking...~1 ns per iteration, which is not enough to compute a hash code.

Edit: I'm being silly. It will just compute the hashcode the first time, and then repeatedly check that it's cached and return it. So the JIT doesn't have to do any _real_ work to make this skip the hash code calculation.

So most likely, the effective code is:

    computeHashCode();
    for (int i = 0; i < 10000; i++) {
        if (false) { // pretend this wouldn't have dead code elimination, and the boolean is actually checked
            computeHashCode();
        }
    }

rzzzt · 2h ago

JMH, the microbenchmark harness has an example that highlights this: https://github.com/openjdk/jmh/blob/master/jmh-samples/src/m...

Calzifer · 15m ago

And since benchmarking is hard is also has a helper to actually "waste" time. [1] The implementation [2] might give an idea that it is not always trivial to do nothing but still appear busy.

Btw I found most of the jmh samples interesting. IMO a quite effective mix of example and documentation. (and I'm not sure there is even much other official documentation)

[1] https://github.com/openjdk/jmh/blob/master/jmh-samples/src/m... [2] https://github.com/openjdk/jmh/blob/872b7203c294d90c17766d19...

mprataps · 1h ago

You are write. This code does not recalculate. However, it was written just as a sample. Mainly user will provide his own method to process the file.

sieve · 2h ago

A note on the name.

The nasal "m" takes on the form of the nasal in the row/class of the letter that follows it. As "ñ" is the nasal of the "c" class, the "m" becomes "ñ"

Writing Sanskrit terms using the roman script without using something like IAST/ISO-15919 is a pain in the neck. They are going to be mispronounced one way or the other. I try to get the ISO-15919 form and strip away everything that is not a-z.

So, सञ्चिका (sañcikā) = sancika

You probably want to keep the "ch," as the average English speaker is not going to remember that the "c" is the "ch" of "cheese" and not "see."

arnsholt · 1h ago

It’s been ages since I did Sanskrit last, but wouldn’t sam-cika typically have the m realized as an anusvara rather than ñ?

sieve · 1h ago

Not unless it precedes a classless letter or it is actually "m."

All nasals becoming anusvaras is something Hindi/Marathi and other languages using the Devanagari script do. Sanskrit uses the specific form of the nasal when available.

mprataps · 1h ago

Guys. I love you all. I did not expect such quality feedback.

I will try to incorporate most of your feedback. Your commments have given me much to learn.

This project was started to just learn more about multithreading in a practical way. I think I succeeded with that.

sidcool · 5h ago

It would be even more amazing if it had tests. It's already pretty good.

mprataps · 1h ago

I will add unit tests next.

DannyB2 · 4h ago

Should the tests include some 10 GB files?

VWWHFSfQ · 4h ago

Should include a script for generating 10GB files maybe

sidcool · 2h ago

Naah. I meant unit tests. Not load tests.

sureglymop · 5h ago

Perhaps I misunderstand something but doesn't reading from a file require a system call? And when there is a system call, the context switches? So wouldn't using multiple threads to read from a file mean that they can't really read in parallel anyway because they block each other when executing that system call?

mike_hearn · 4h ago

System calls aren't context switches. They flip a permission bit in the CPU but don't do the work a context switch involves like modifying the MMU, flushing the TLBs, modifying kernel structures, doing scheduling etc.

Also, modern filing systems are all thread safe. You can have multiple threads reading and even writing in parallel on different CPU cores.

bionsystem · 4h ago

If you open() read-only I don't think it blocks (some other process writing to it might block though).

porridgeraisin · 2h ago

> system call, the context switches

No, there is no separate kernel "executing". When you do a syscall, your thread becomes kernel mode and it executes the function behind the syscall, then when it's done, your thread reverts to user mode.

A context switch is when one thread is being swapped out for another. Now the syscall could internally spawn a thread and context switch to that, but I'm not sure if this happens in read() or any syscall for that matter.

codetiger · 5h ago

Do you have a benchmark comparison with other similar tools?

VWWHFSfQ · 4h ago

Am I wrong in thinking that this is duplicating lines in memory repeatedly when buffering lines into batches, and then submitting batches to threads? And then again when calling the line processor? Seems like it might be a memory hog

Calzifer · 8m ago

Since most things in Java are handled by reference, including Strings there should be not that much memory overhead. From a quick look I could not find any actual line duplication.

gavinray · 5h ago

Please don't do this.

Have the OS handle memory paging and buffering for you and then use Java's parallel algorithms to do concurrent processing.

Create a "MappedByteBuffer" and mmap the file into memory.

If the file is too large, use an "AsynchronousFileChannel" and asynchronously read + process segments of the buffer.

papercrane · 5h ago

If you're using a newer JVM you can also map a "MemorySegment", which doesn't have the 2GiB limit that byte buffers have.

gavinray · 4h ago

Good point, have written about this in the past

https://gavinray97.github.io/blog/panama-not-so-foreign-memo...

90s_dev · 5h ago

Knowing nothing about Java or compsci, I am very curious to see the in depth discussion by all you Java/compsci experts that your comment invites.

switchbak · 4h ago

Memory mapping is fun, but shouldn't we have some kind of async IO / uring support by now? If you're looking at really high-perf I/O, mmaping isn't really state of the art right now.

Then again, if you're in Java/JVM land you're probably not building bleeding edge DBs ala ScyllaDB. But I'm somewhat surprised at the lack of projects in this space. One would think this would pair well with some of the reactive stream implementations so that you wouldn't have to reimplement things like backpressure, etc.

jlokier · 5m ago

Last time I measured on Linux (a few years ago), with NVMe, mmap + calling out to a thread pool to async-page-touch (so the main thread didn't block) was faster than io_uring (from the main thread) for random access reads.

threeseed · 54m ago

a) There have been libraries supporting io_uring on the JVM for many years now.

b) SycllaDB is not bleeding edge. It uses the relatively old now DPDK.

c) There are countless reactive stream implementations e.g. https://vertx.io/docs/vertx-reactive-streams/java/

exabrial · 2h ago

try not to be a dick

SillyUsername · 3h ago

Better caveat that with, "but watch memory consumption, given the nature of the likes of CopyOnWriteArraylist". GC will be a bitch.

mprataps · 1h ago

Thanks for this comment. This will be an interesting aspect to explore.

ldjkfkdsjnv · 3h ago

I could write this library with an llm in a few hours

threeseed · 48m ago

No different to cheating off someone at school.

You didn't learn anything. You didn't accomplish anything. And no one including you respects it.

mprataps · 1h ago

May be. I just started this with the intention to learn about multithreading. I learnt a lot of concepts which I had earlier only learnt in theory. I learnt how to use VisualVM to see my thread performance. I learnt to use builder design pattern. No LLM can take away this learning.

And this project is just a start.

bogeholm · 1h ago

I could probably do an Ironman if I really wanted to

SillyUsername · 3h ago

An ArrayList for huge numbers of add operations is not performant. LinkedList will see your list throughput performance at least double. There are other optimisations you can do but in a brief perusal this stood out like a sore thumb.

pkulak · 3h ago

I've literally never seen a linked list be faster than an array list in a real application, so if you're right, this is kinda huge for me.

fedsocpuppet · 3h ago

Huh? It'll be slower and eat a massive amount of memory too.