|
|
Rank: Member
Groups: Member
Joined: 10/17/2013
Posts: 22
|
I did few HTML to PDF conversions, and noticed the disk space increases significantly,
although from time to time it is reduced in a cyclic way.
I assume it is due to use of a work area, which is cleaned when a limit is reached.
I testes an input file size of ~9 MB (HTML+images), and a PDF output file size of ~6 MB.
I noticed disk space usage increase of up to 2 GB.
Do I have an API to clean it after the action, or do I have access to the location from my code to clean it myself?
Thanks,
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
This doesn't seem to have anything to do with us. In most cases the whole conversion is done in memory, we do not write temp file on disk at all. We only try to "swap out" certain contents to disk in extremely low memory situation as a last resort to avoid an out of memory crash, but its unlikely that will reach 2GB in size.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 10/17/2013
Posts: 22
|
Hi,
I checked again the next scenario:
1. Close all Programs.
2. Open file explorer.
3. Execute EO HTML to PDF tools
4. Check Drive C: Used Space - 138,254,708,736 bytes
5. Convert URL to PDF (HTML+Images input size: ~9MB)
6. Select No for opening the PDF after conversion. (to avoid noise from the PDF reader)
7. Check Drive C: Used Space - 139,571,441,664 bytes
The Difference is ~1.3 GB
Is it possible that a 3rd party you use (e.g. Microsoft or Adobe component) consume this resource?
Thanks,
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
No. We do not use any third party components. One of the biggest advantage of our HTML to PDF converter is it has zero external dependency.
It is possible that Windows will create certain temp files during the process. However in that case Windows will manage or release that disk space in that case. Also as mentioned in our previous post, it is possible that our converter will create temp files under extreme load conditions, however I doubt that would happen or reaches 1.3GB in size, and even if that occurs, the converter will release it at a later time.
In any case, I do not believe you should be alarmed about disk space fluctuation during a single conversion. If you have the program running for a long time and observed that disk space keeps growing, then it could be a concern. However our product has been on the market for years and we have not had any report on disk space issues.
Thanks!
|
|
Rank: Member
Groups: Member
Joined: 10/17/2013
Posts: 22
|
Hi,
We did some research, and found 1.3 GB files named <number>.eods,
under - C:\Users\<user>\AppData\Local\Temp\eods.
As mentioned earlier, when I tested few conversions, the disk space increased by up to ~6 GB, and them decreased, in a cyclic way.
I considered deleting them myself, but the location is OS dependent.
Our application produces large PDFs (e.g. 1500 in my test, and larger by our customers)
Cleanup after the conversion (automatic or by an API call) can be helpful.
Thanks,
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
Hi, we do create files in the "eods" folder when the system is under stress. However the converter will clean them up regularly. You do not need to clean them up, and you should not clean them up because you would not know when they are being used. The temp file are used to swap out certain contents from memory to avoid an out of memory crash.
However the size of the file does not sound normal if both input HTML file and output PDF file is only a few MBs. So if you can send us an HTML file we will be happy to investigate further. We will PM you as to where to send the test file.
Thanks!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
We have looked into the test files you sent to us. The reason that it took a lot of disk space is because of the images. First because the HTML file has a lot of pages, it quickly triggered a low memory condition. Once that occurs, the images are being swapped out to the disk. The reasons that it took so much disk space is because the images are PNG format, which has built-in support for transparency. The way PDF supports transparency is to have two images: one that is the actual image, and another one is a "mask", whose whole purpose is to define the alpha channel. This significantly increases memory uses. Also the built-in PDF image format is JPG, so every PNG images has to be completely decoded as bitmap in memory and then encoded again. This along with the large number of pages causes a lot of memory swapping thus creating significant amount of temp files.
However you should not be concerned about the temp files. They will be automatically deleted by the converter. So it will not accumulate. The temp file is a way that our converter uses to avoid a straight out of memory crash. This is what gives our converter the ability to handle big HTML files and the temp file mechanism has been well tested.
Thanks!
|
|