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

Study & Improve Image Size #50

Open
dduportal opened this issue Oct 22, 2017 · 7 comments
Open

Study & Improve Image Size #50

dduportal opened this issue Oct 22, 2017 · 7 comments

Comments

@dduportal
Copy link
Contributor

dduportal commented Oct 22, 2017

After #39, #46 and #47 have increased the size of the image (protip: I might be the person responsible on this by missing knowledge on Ruby Gems / Native Alpine Package).

Helped has been asked in #47 on this, and we might be able to improve this in the future.

I propose that we first implement a CD process where logs are available with testing harness (cf proposal in #49 ) before jumping on this topic.

What would be your thoughts @mojavelinux @jirutka and the community?

[EDIT] The size increased was caused by the "return" of the JRE OpenJDK 8 installation in #46

@jirutka
Copy link
Member

jirutka commented Oct 22, 2017

Do you really need full JRE? I guess that openjdk8-jre-base (aka headless) should be enough.

@dduportal
Copy link
Contributor Author

Hello @jirutka, thanks for this tip.

I tried locally to move to the headless JRE (instead of the JRE), and ended on this error:

Exception in thread "main" java.lang.UnsatisfiedLinkError: no fontmanager in java.library.path
   	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
   	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
   	at java.lang.System.loadLibrary(System.java:1122)
   	at sun.font.FontManagerNativeLibrary$1.run(FontManagerNativeLibrary.java:61)
   	at java.security.AccessController.doPrivileged(Native Method)
   	at sun.font.FontManagerNativeLibrary.<clinit>(FontManagerNativeLibrary.java:32)
   	at sun.font.SunFontManager$1.run(SunFontManager.java:339)
   	at java.security.AccessController.doPrivileged(Native Method)
   	at sun.font.SunFontManager.<clinit>(SunFontManager.java:335)
   	at sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:264)
   	at sun.java2d.SunGraphics2D.getFontMetrics(SunGraphics2D.java:864)
   	at net.sourceforge.plantuml.FileFormat$2.calculateDimension(FileFormat.java:99)
   	at net.sourceforge.plantuml.creole.AtomText.calculateDimension(AtomText.java:144)
   	at net.sourceforge.plantuml.creole.Sea.add(Sea.java:51)
   	at net.sourceforge.plantuml.creole.SheetBlock1.initMap(SheetBlock1.java:106)
   	at net.sourceforge.plantuml.creole.SheetBlock1.calculateDimension(SheetBlock1.java:148)
   	at net.sourceforge.plantuml.creole.SheetBlock2.calculateDimension(SheetBlock2.java:65)
   	at net.sourceforge.plantuml.graphic.TextBlockMarged.calculateDimension(TextBlockMarged.java:59)
   	at net.sourceforge.plantuml.svek.HeaderLayout.getDimension(HeaderLayout.java:65)
   	at net.sourceforge.plantuml.svek.image.EntityImageClassHeader2.calculateDimension(EntityImageClassHeader2.java:178)
   	at net.sourceforge.plantuml.svek.image.EntityImageClass.calculateDimension(EntityImageClass.java:97)
   	at net.sourceforge.plantuml.svek.DotDataImageBuilder.printEntity(DotDataImageBuilder.java:277)
   	at net.sourceforge.plantuml.svek.DotDataImageBuilder.printEntities(DotDataImageBuilder.java:268)
   	at net.sourceforge.plantuml.svek.DotDataImageBuilder.buildImage(DotDataImageBuilder.java:138)
   	at net.sourceforge.plantuml.svek.CucaDiagramFileMakerSvek.createFileInternal(CucaDiagramFileMakerSvek.java:99)
   	at net.sourceforge.plantuml.svek.CucaDiagramFileMakerSvek.createFile(CucaDiagramFileMakerSvek.java:65)
   	at net.sourceforge.plantuml.cucadiagram.CucaDiagram.exportDiagramInternal(CucaDiagram.java:334)
   	at net.sourceforge.plantuml.classdiagram.ClassDiagram.exportDiagramInternal(ClassDiagram.java:202)
   	at net.sourceforge.plantuml.UmlDiagram.exportDiagramNow(UmlDiagram.java:231)
   	at net.sourceforge.plantuml.AbstractPSystem.exportDiagram(AbstractPSystem.java:129)
   	at net.sourceforge.plantuml.SourceStringReader.outputImage(SourceStringReader.java:149)
   	at net.sourceforge.plantuml.SourceStringReader.outputImage(SourceStringReader.java:121)
   	at org.asciidoctor.diagram.plantuml.PlantUML.generate(PlantUML.java:105)
   	at org.asciidoctor.diagram.CommandProcessor.processRequest(CommandProcessor.java:40)
   	at org.asciidoctor.diagram.CommandServer.processRequests(CommandServer.java:58)
   	at org.asciidoctor.diagram.CommandServer.main(CommandServer.java:25)
   asciidoctor-diagram: ERROR: Failed to generate image: end of file reached

I tried to explicitly install fontconfig and ttf-dejavu but it was not solving the stack. I did not try much more to be honest.

For information, the size gain was ~3 Mb based on the docker image ls command output (435 Mb instead of 438 Mb).

@lurch
Copy link

lurch commented Oct 3, 2019

I guess the suggestion of a smaller "base" image in #54 relates to this issue also?

@reitzig
Copy link
Contributor

reitzig commented Feb 17, 2021

Bumping this since the size increased _significantly from ~250MB (1.2) to ~440MB (1.3) as listed on DockerHub; local docker images lists them as ~470MB and ~1.5GB (!!), respectively.

From a user perspective after reading the changelog, it's completely unclear to me where this increase comes from.


After analysis, it seems the increase is fully due to #166 :

image

Seems to be that a feature some might need shouldn't have this much of a size impact, but that's of course for the maintainers to trade off.

Guess: Cleaning out cabal caches and removing all the dev packages again should decrease the image size dramatically.
Recommendation: For dependency-heavy compilations of which we only want the result in the final file, I can recommend multi-stage builds.

@dduportal
Copy link
Contributor Author

Thanks @reitzig for pointing the fact that #166 added a 1 Gb size penalty 😱.

If you have any knowledge on the cabal package system, it could be a great help to have a contribution. Would you be up for the challenge?

There is an opportunity here to contribute to Alpine Linux by adding a native erd package.

We can also revert #166 time to find a viable solution in term of size, WDYT?

@dduportal
Copy link
Contributor Author

@reitzig I started #175 : feel free to use it, push to it, etc.

@reitzig
Copy link
Contributor

reitzig commented Feb 17, 2021

If you have any knowledge on the cabal package system, it could be a great help to have a contribution. Would you be up for the challenge?

Not really. I've used cabal to install pandoc before and blew up my backup in the process, so that's what triggered me here.

I'll see if I can quickly fix the Dockerfile; I won't be able to do any testing, though. (Are there automated tests of any form?)

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