Summary: | [Patch] Faster AES decryption | ||
---|---|---|---|
Product: | poppler | Reporter: | Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b> |
Component: | general | Assignee: | poppler-bugs <poppler-bugs> |
Status: | RESOLVED MOVED | QA Contact: | |
Severity: | enhancement | ||
Priority: | medium | CC: | 0xe2.0x9a.0x9b |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | faster-aes.diff |
Description
Jan Ziak (http://atom-symbol.net)
2014-05-17 13:28:04 UTC
Can you provide the PDF file you tried it on and some benchmark results before and after? (In reply to comment #1) > Can you provide the PDF file you tried it on and some benchmark results > before and after? The PDF is http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html?iid=tech_vt_tech+64-32_manuals, Combined Volumes 2A, 2B, 2C. With -O0 passed to the C compiler: opening the PDF takes 5.9 seconds without the patch, 4.1 seconds with the patch. This was measured on a 4.0 GHz AMD CPU. Any news on merging this patch? Hi, I'm not sure that initializing the arrays through that MulTableInit class is a good idea. Relying on a global/static variable ctor is usually discouraged, because it's hard to predict the order those variables are initialized. In order words, what happens if you open an encrypted document from another global/static variable's ctor? Has the decryption table been initialized already or not? http://www.parashift.com/c++-faq/static-init-order-on-first-use.html (In reply to comment #4) > Hi, I'm not sure that initializing the arrays through that MulTableInit > class is a good idea. > > Relying on a global/static variable ctor is usually discouraged, because > it's hard to predict the order those variables are initialized. In order > words, what happens if you open an encrypted document from another > global/static variable's ctor? Has the decryption table been initialized > already or not? I see. I suggest we introduce a boolean variable that we would check before every AES decryption. Would this be OK with you? Does the variable need to be thread-safe? Why would you use O0? HAve you tried with O2? For file you mean http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf no? I'm a bit surprised opening the file takes 4 seconds, can you define what "opnening the file" means since i basically open it in no time (0,008 seconds). (In reply to comment #6) > Why would you use O0? HAve you tried with O2? This has no significance. > For file you mean > http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32- > architectures-software-developer-instruction-set-reference-manual-325383.pdf > no? I'm a bit surprised opening the file takes 4 seconds, can you define > what "opnening the file" means since i basically open it in no time (0,008 > seconds). You used "open it" in your sentence without defining it. The measured time refers to userspace time as reported by "time okular some.pdf". (In reply to comment #7) > (In reply to comment #6) > > Why would you use O0? HAve you tried with O2? > > This has no significance. Have you tried? > > For file you mean > > http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32- > > architectures-software-developer-instruction-set-reference-manual-325383.pdf > > no? I'm a bit surprised opening the file takes 4 seconds, can you define > > what "opnening the file" means since i basically open it in no time (0,008 > > seconds). > > You used "open it" in your sentence without defining it. > > The measured time refers to userspace time as reported by "time okular > some.pdf". Well, i don't need to define what open means, open a file is opening, basically the time that glib/demo/poppler-glib-demo reports it took in opening it. What you mention is pretty unscientific. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/85. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.