Remix.run Logo
robin_reala 2 days ago

Note: log scale on the y axis. Current Adobe reader is 83x bigger than current Sumatra according to the chart.

wanderingstan 2 days ago | parent | next [-]

Yes. Log scale seems like a poor choice, given that the point is to show the relative size disparity.

StrangeDoctor 2 days ago | parent [-]

For a technical audience, it’s probably one of the better choices, it’s probably a poor one for mass consumption.

A purely linear graph would absolutely crush their pdf installer and the first 15 years of adobe into a flat line

fooofw 2 days ago | parent | next [-]

For reference, here's a version with a linear y-axis: https://imgur.com/a/A2D1puk

qualeed 2 days ago | parent | next [-]

For the purposes of this article, this graph is much more effective at making the point than the log scale one. I think it would have been a better choice to use a graph like this.

Thanks!

ginko 2 days ago | parent [-]

But you can barely tell the growth of sumatrapdf in the non-logarithmic chart. Same for Adobe Reader before 2000 or so.

qualeed 2 days ago | parent [-]

For the purposes of what this post is communicating, I don't think the exact sizes of adobe prior to 2000 or the exact size of sumatrapdf matters at all.

The linear graph instantly communicates:

    - sumatrapdf has barely changed size in the same time that adobe's size has grown exponentially

    - adobe's crazy growth spike started ~6 years ago
Maybe I'm just dumb, but I didn't realize the graph had a log y-axis at first. Then, once I realized that, I had to spend a bit of time parsing the graph to figure out what it was saying (I don't work with log graphs often at all). And once that was done, the only thing I came away with was "wow, adobe grew a hell of a lot when sumatra didnt", which is the same thing the linear graph told me instantly.

Being able to see that sumatras size remains relatively flat while adobes size growth is practically vertical is all the granularity I care about at a glance. If I want to know exact sizes, I'll dive in deeper.

wat10000 2 days ago | parent [-]

I think this is an argument for the log scale. I'd argue that the things you say it communicates are not actually correct.

Adobe's size has been growing exponentially pretty much this whole time. The rate increased slightly in the mid-2010s. SumatraPDF started out that way too, but managed to level out after about a decade.

Relative size is what matters here. That increase from ~2.5MB to ~5MB in the mid-90s was pretty significant for the time. In terms of the impact on users, it's probably at least as important if not more so than going from 300MB to 600MB 25-30 years later.

qualeed 2 days ago | parent | next [-]

>Relative size is what matters here.

This is where our disconnect is. Relative change in size means nothing to me. I care about the absolute size of the final thing I'm installing.

Adobe big, getting bigger. Sumatra small, staying small.

conductr 2 days ago | parent | prev [-]

I disagree, am with qualeed on this one. I don’t think the size doubling means much at all except raising the question of why did it double? What was added that I care about? My instinct tells me nothing so it’s shouldn’t really be acceptable except this is par for the course these days. Nobody cares about bandwidth it’s just assumed to be fast and unlimited by nearly every publisher of software.

In the 90s that jump cost me in terms of modem time. I couldn’t download anything else for an extra 30-60 minutes that day (if I remember my speeds correctly). Today, extra 300mb costs me less than a minute and I can easily continue multitasking in the process.

wat10000 2 days ago | parent [-]

Imagine there had been a 50MB jump in 1998. That would be a major WTF moment. Now imagine a 50MB jump in 2025. We'd barely notice.

Saying Adobe's crazy growth spike started six years ago is just pointing to the knee in the exponential curve. It's had pretty much the same curve since version 1.0. And SumatraPDF had the same exponential growth for quite a while.

If absolute numbers are what matters and an extra 300MB is not important, then why not scale the Y axis to 1TB and squash everything to the bottom?

bigstrat2003 2 days ago | parent | prev | next [-]

Thank you! That graph is so much clearer than the one in the article. You can see at a glance the relative size of the two programs, which the logarithmic scale does a terrible job showing.

Night_Thastus 2 days ago | parent | prev [-]

This makes way more sense if the point was to show how big and bloated Adobe Reader has gotten, and by comparison just how space-efficient Sumatra is.

Way more representative.

bigstrat2003 2 days ago | parent | prev [-]

I'm a technical audience and the logarithmic scale is meaningless to me. So I don't even agree that it's a good choice for a technical audience. It may be a good choice for people who already are used to reading logarithmic scales, but that can't be a particularly large group as it's very rare to see a graph like that.

chrismorgan 2 days ago | parent | prev [-]

I looked at the graph first, and misread the version numbers as sizes in megabytes, because that yielded stuff that wasn’t far off matching the curve linearly. “25.1 MB?” I said. “Huh, I’d have expected a lot more than that, but… maybe it’s just ultra compressed? Somehow? Still seems a bit too small. But maybe this article is actually praising Adobe for keeping it down.”

Then Sumatra being 3.something MB seemed possible, for a well-compressed installer.

Ugh, some of these sizes are absurd. I still remember Zoom basically doubling in a single release, as they put a second entire web browser inside the package.