Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's a bit of a roundabout article, given that it's ostensibly talking about the Web version of Photoshop. Basically, Adobe already solved the problem (for decades, now) with a traditional non-web application by using the filesystem. And the new bit here is that Chrome offers a filesystem for web apps to use [1], so from the web app's point of view, it can still use the same essential solution that the native app would.

It doesn't really go into the guts of how PS actually manages all that data in much detail. Just "it goes to the filesystem in a smart way."

[1] The "origin private file system": https://developer.chrome.com/articles/file-system-access/#ac...



... application-based virtual memory has been a thing since CICS on mainframes back in the 1970s.


Photoshop can't rely on mmap, because its scratch file implementation is older than most modern OSes, and some systems have virtual memory limits it exceeds, not just physical memory limits. Though I'm not sure the browser even has mmap capability.


They used coding and filesystems so the webpages didn't crash.


They created a GUI using Visual Basic to track the killer's IP


It's unfortunate that there's still no mmap equivalent for I/O in the browser, so you can't do demand paging or anything like that. Nothing approaching zero-copy either, you're typically looking at two copies or more. At least the OS page cache will probably help you out.


Scratch files, now that's a memory I'd repressed.


Make sure you keep your scratch files on a separate disk for extra performance! 8)


I remember someone I knew that insisted on using a ram disk as his scratch disk...

Like, uh.... ok, you do that, good luck.


In the late 80's/early 90's, it was one of the few ways to run large videos (for the time) without stuttering bc hard drives were too slow.


There was a time when the OS could not use the whole RAM directly the hardware had, and it was a use case to put a ram disk or a swap file there.


If the OS can't see the RAM, then the OS provided ramdisk can't use it either.

But in this case, the use-case for using a ramdisk for a PS scratch disk came from using an A23-aware patched version of System 5.x/6.x with a version of Photoshop that was not A23 aware. AFAIK This was a VERY tiny window around PS1.0 and possibly PS2.0, by the time of PowerPC and System 7.5+ (which this user had), there was very definitely absolutely no advantage to partitioning the RAM away from programs.

At a guess, someone had told them to do it this way in the era of the early Mac IIs and such, but they hadn't grasped the 'why'



If the app was from an era where RAM was much smaller, but now there's enough RAM for the use case, this makes sense.


Linux is full of stuff that writes to disk all the time.

Browsers do it too. It's possible to do multiple GB an hour doing nothing on some versions with extensions, just from writing and rewriting the same file every minute for probably no good reason other than a dev hated complexity too much to check for unnecessary writes and not wear out the SSD.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: