Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Empty grain size is quite big #12

Open
zertrin opened this issue Apr 25, 2020 · 4 comments
Open

Empty grain size is quite big #12

zertrin opened this issue Apr 25, 2020 · 4 comments

Comments

@zertrin
Copy link

zertrin commented Apr 25, 2020

Hello!

I just tried CodiMD on sandstorm and quite like the app.

However, a newly created grain with no content already weigh 48.4 MB!
This overhead for just a text note seems very excessive to me.

Do you think there is anything that can be done to make the grains more lightweight in the future?

@nicolas-arnold
Copy link

I made the same observation. There also exists SandMD (Last updated: 2018 Dec 27) whereas CodiMD seems to be more up to date (Last updated: 2020 Apr 29).

I tried CodiMD as I had several issues with unresponsive SandMD pads, but an empty pad over there has about 90kb for me. As both have the same origin, I consider ~50 MB for an empty pad indeed a bug and it's a reason not to use this version, although it might be more stable in general.

Has that ever been so and is there an explanation for why it's so big? What is stored individually besides the text and some metadata itself upfront?

@bingluen
Copy link
Contributor

According to CodiMD official document:

We will only support PostgreSQL and MySQL in future database migrations, if any.

We choose MySQL as database to storage data.
SandMD, we previously published, use SQLite file to storage data.
That's why CodiMD's grain size is bigger than SandMD.

I refer platform stacks from Sandstorm official document to build MySQL environment for CodIMD.

It maybe not best practice that I current implement on CodiMD's Sandstorm app.

Welcome to discuss, if you have any idea to optimize

@zertrin
Copy link
Author

zertrin commented Jul 24, 2020

This is very unfortunate, and in my case, a deal-breaker for usage of CodiMD on sandstorm.

A single overhead of 48 MB for all notes would be acceptable (e.g. if I were to install CodiMD directly, not on sandstorm), but a repeated overhead of 48 MB per note is just not acceptable for me.

Thanks for the explanation though! Good luck in finding a solution 🙂

@ocdtrekkie
Copy link
Contributor

Yeah, unfortunately, MySQL isn't a great fit for Sandstorm apps because of it's overhead. It isn't too big a deal with TinyTinyRSS, for instance, where you're likely to only have one or two grains, but it can be painful for single-document apps.

Presumably someone could update SandMD, but I assume @bingluen is only going to invest time/effort in supporting the package that PDIS is using.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants