Hi Aleksei,
Is there any update regarding the issue discussed, specifically the slow document loading you were investigating?
Thanks,
Abhinay Patel
Hello,
Thank you for following up.
We are still investigating the issue related to the slow document loading. Our team is actively analyzing the root cause, and we will provide you with an update as soon as we have more information.
Thank you for your patience and understanding.
Best regards,
Aleksei
is there is any update on this?
We analyzed the reasons for the slow performance when working with large PDF files.
First of all, we would like to emphasize that this code is part of a basic sample (demo) application, intended to demonstrate integration and core functionality. It is not designed for production use or large-scale/high-load scenarios without additional optimization.
Main performance bottlenecks
1. Loading all document pages at once (critical)
Issue:
The current configuration uses preloadPageCount: 0, which causes all pages to be loaded and rendered when the document is opened.
For a 100-page PDF, this means rendering all 100 pages at the same time, significantly increasing load time and resource consumption.
Code:
# configuration.yml (line 61)
preloadPageCount: 0
// AnnotationServiceImpl.java (lines 167–169)
if (loadAllPages) {
pagesContent = getAllPagesContent(password, guid, info);
}
2. Creating a new Annotator instance for each page (critical)
Issue:
In the getAllPagesContent() method, a new Annotator instance is created for each page.
For large documents, this results in repeatedly opening and closing the same document (e.g., 100 times for a 100-page file), which has a significant negative impact on performance.
Code:
// AnnotationServiceImpl.java (lines 482–499)
private List<String> getAllPagesContent(String password, String documentGuid, IDocumentInfo pages) {
List<String> allPages = new ArrayList<>();
for (int i = 0; i < pages.getPageCount(); i++) {
byte[] bytes;
try (OutputStream memoryStream = renderPageToMemoryStream(i + 1, documentGuid, password)) {
ByteArrayOutputStream bos = (ByteArrayOutputStream) memoryStream;
bytes = bos.toByteArray();
} catch (IOException ex) {
throw new TotalGroupDocsException(ex.getMessage(), ex);
}
String encodedImage = new String(Base64.getEncoder().encode(bytes));
allPages.add(encodedImage);
}
return allPages;
}
3. Reopening the file for each page
Issue:
In the renderPageToMemoryStream() method, the file is opened again for each page.
For multi-page documents, this leads to multiple disk read operations, which is another major performance bottleneck.
Code:
// AnnotationServiceImpl.java (lines 263–297)
private static OutputStream renderPageToMemoryStream(int pageNumberToRender,
String documentGuid,
String password) {
try {
OutputStream result = new ByteArrayOutputStream();
InputStream inputStream = new FileInputStream(documentGuid);
try {
final Annotator annotator = new Annotator(inputStream, getLoadOptions(password));
// ... render a single page
} finally {
// resource cleanup
}
}
}
For real-world production scenarios and working with large PDF files, this sample requires further tuning and optimization (lazy page loading, resource reuse, minimizing I/O operations, etc.).
Hi,
We have optimized these points we are loading preload page count =1 also we have corrected the other point as well still it takes time in loaddocumentdescription only while creating annotator object it takes most of the time and similar other intilization why
Do you have some optimized version or other code which I can try as its takes 1-2 minutes in loading a document which is slow if it can be some seconds that will be good
Hi,
Could you please share your full project and the test document where this issue occurs? This will help us investigate why the initialization takes so long.
I have this repo for backend GitHub - groupdocs-annotation/GroupDocs.Annotation-for-Java-Spring: Moved to https://github.com/groupdocs-annotation/GroupDocs.Annotation-for-Java/tree/master/Demos/Spring and https://www.npmjs.com/package/@groupdocs.examples.jquery/annotation this in frontend
I just set the preload count =1
and some small changes in that if you can optimize this code it will work fine
pdf you can take any more than 50 to 100 pages all were slow only sometimes even with 20 or 1 page is slow
Hi Aleksei,
I have already shared the standalone application that I have integrated into my project. Could you please provide the corrections directly within that sample?
Thanks,
Abhinay Patel
Hello,
Updated: GitHub - groupdocs-annotation/GroupDocs.Annotation-for-Java: GroupDocs.Annotation for Java examples, plugins, and showcase · GitHub
Improvements Made
1. Document Session Cache (DocumentSession)
Previously, each page request created a new Annotator instance, requiring a full PDF parse. Now the Annotator, document metadata, and annotation list are cached for 30 minutes. The document is parsed once on first open, and all subsequent requests use the already-open session.
2. Eliminated Duplicate Parsing on Page Load
The getDocumentPage() method created 2 Annotator instances per request — one for metadata, another for rendering. Now a single cached instance is used.
3. Optimized All-Pages Loading
When loading all pages (e.g., for printing), a new Annotator was previously created for each page. Now a single cached session is used for all pages.
4. Rendered Page Image Cache
Added a cache for page PNG images. The cache key accounts for file path, modification date, and page number. On repeated requests for the same page, the image is served from memory without re-rendering. TTL is 30 minutes with auto-cleanup above 500 entries.
5. New Streaming Endpoint for Page Images
Added GET /annotation/pageImage, which serves PNG directly, bypassing Base64 encoding and JSON wrapping. This eliminates the 33% data transfer overhead. The response includes Cache-Control and ETag HTTP headers for browser-side caching.
6. Fixed Page Preload Configuration
The preloadPageCount parameter was set to 0 (load all pages at once). For a large PDF, this meant rendering all pages to PNG on document open. Changed to 1 — only the first page is loaded, the rest load on scroll.
7. License Configuration
Set the license file path. Without a license, trial mode blocked documents over 4 pages.
8. Fixed Silent Error Swallowing
An IOException was caught and ignored — the client received an empty response with no indication of the cause. Replaced with proper logging and error propagation with an informative message.
9. Cache Invalidation on Annotation
When annotations are saved, the cached document session is invalidated so the next request receives up-to-date data.
Results
| Scenario | Before | After |
|---|---|---|
| 756-page PDF | ||
| Opening document | Would not open (trial) / minutes | ~62 sec |
| Loading each subsequent page | ~62 sec | < 1 sec |
| Repeated page request | ~62 sec | Instant (cache) |
| Reopening the same document | ~62 sec | Instant (session) |
| 100-page PDF | ||
| Opening document | ~8 sec + loading all 100 pages | ~8 sec (metadata only) |
| Loading each subsequent page | ~8 sec (re-parsing) | < 1 sec |
| Repeated page request | ~8 sec | Instant (cache) |
| Reopening the same document | ~8 sec | Instant (session) |
| General | ||
| Image transfer | Base64 in JSON (+33%) | Direct PNG + HTTP cache |
Thank you
Thanks for help can you fix these two repo as well GitHub - groupdocs-viewer/GroupDocs.Viewer-for-Java: GroupDocs.Viewer for Java - Examples and Demo Projects · GitHub and GitHub - groupdocs-signature/GroupDocs.Signature-for-Java: GroupDocs.Signature for Java examples, plugins and showcase projects · GitHub version I have upgraded alreday
We’ve logged these feature requests, but at the moment we’re not able to provide an ETA for their implementation.
If accelerating their priority is important for you, this can be addressed through our paid support options.
In any case, we really appreciate your feedback and usage of the product — insights like yours help us improve and better understand real-world use cases.