Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2251333002:
Use a map for app::m_Timers (Closed)
DescriptionUse a map for app::m_Timers
Currently the timers is a vector. When we cancel a timer we have an O(n) operation
to remove the timer. If there are a lot of timers (which this test has > 16k) this can
take a long time. The impact is a lot lower in Release, but the test is very slow in Debug.
From Linux on waterfall:
[ RUN ] FPDFFormFillEmbeddertest.BUG_634716
[ OK ] FPDFFormFillEmbeddertest.BUG_634716 (7855 ms)
From Linux try bot:
[ RUN ] FPDFFormFillEmbeddertest.BUG_634716
[ OK ] FPDFFormFillEmbeddertest.BUG_634716 (431 ms)
From Linux XFA Rel GYP on waterfall:
[ RUN ] FPDFFormFillEmbeddertest.BUG_634716
[ OK ] FPDFFormFillEmbeddertest.BUG_634716 (185 ms)
From Linux XFA Rel GYP try bot:
[ RUN ] FPDFFormFillEmbeddertest.BUG_634716
[ OK ] FPDFFormFillEmbeddertest.BUG_634716 (72 ms)
Committed: https://pdfium.googlesource.com/pdfium/+/2eb7c7dd6392488d858989da8d57d618f58f04ca
Patch Set 1 #
Total comments: 6
Patch Set 2 : Review feedback #
Total comments: 2
Messages
Total messages: 21 (12 generated)
The CQ bit was checked by dsinclair@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== Use a map for app::m_Timers In debug this is by far the slowest test (taking upwards of 6seconds). The test is fast in Release. From the Linux Builder: [ RUN ] FPDFFormFillEmbeddertest.BUG_634716 [ OK ] FPDFFormFillEmbeddertest.BUG_634716 (7855 ms) ========== to ========== Use a map for app::m_Timers Currently the timers is a vector. When we cancel a timer we have an O(n) operation to remove the timer. If there are a lot of timers (which this test has > 16k) this can take a long time. The impact is a lot lower in Release, but the test is very slow in Debug. From Linux on waterfall: [ RUN ] FPDFFormFillEmbeddertest.BUG_634716 [ OK ] FPDFFormFillEmbeddertest.BUG_634716 (7855 ms) From Linux try bot: [ RUN ] FPDFFormFillEmbeddertest.BUG_634716 [ OK ] FPDFFormFillEmbeddertest.BUG_634716 (431 ms) From Linux XFA Rel GYP on waterfall: [ RUN ] FPDFFormFillEmbeddertest.BUG_634716 [ OK ] FPDFFormFillEmbeddertest.BUG_634716 (185 ms) From Linux XFA Rel GYP try bot: [ RUN ] FPDFFormFillEmbeddertest.BUG_634716 [ OK ] FPDFFormFillEmbeddertest.BUG_634716 (72 ms) ==========
dsinclair@chromium.org changed reviewers: + thestig@chromium.org, tsepez@chromium.org
PTAL. This is probably not a huge issue in the wild as I'd be surprised if there were this many timers, but it shows up as a noticeable pause when running the embedder tests.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Nice find. https://codereview.chromium.org/2251333002/diff/1/fpdfsdk/javascript/app.cpp File fpdfsdk/javascript/app.cpp (right): https://codereview.chromium.org/2251333002/diff/1/fpdfsdk/javascript/app.cpp#... fpdfsdk/javascript/app.cpp:553: m_Timers[timerRef] = std::move(timer); Can this be a std::set then? https://codereview.chromium.org/2251333002/diff/1/fpdfsdk/javascript/app.cpp#... fpdfsdk/javascript/app.cpp:629: auto iter = m_Timers.find(pTimer); Don't bother, just m_Timers.erase(pTimer), which does a find() internally. https://codereview.chromium.org/2251333002/diff/1/fpdfsdk/javascript/app.h File fpdfsdk/javascript/app.h (right): https://codereview.chromium.org/2251333002/diff/1/fpdfsdk/javascript/app.h#ne... fpdfsdk/javascript/app.h:11: #include <vector> IWYU
The CQ bit was checked by dsinclair@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2251333002/diff/1/fpdfsdk/javascript/app.cpp File fpdfsdk/javascript/app.cpp (right): https://codereview.chromium.org/2251333002/diff/1/fpdfsdk/javascript/app.cpp#... fpdfsdk/javascript/app.cpp:553: m_Timers[timerRef] = std::move(timer); On 2016/08/18 06:16:19, Lei Zhang wrote: > Can this be a std::set then? No, we need to have the find() be fast. The find receives the GlobalTimer* as the input, but we want std::unique_ptr<GlobalTimer> in the set. So, we'd have to search the whole set to find the timer, incurring the same cost as before. https://codereview.chromium.org/2251333002/diff/1/fpdfsdk/javascript/app.cpp#... fpdfsdk/javascript/app.cpp:629: auto iter = m_Timers.find(pTimer); On 2016/08/18 06:16:19, Lei Zhang wrote: > Don't bother, just m_Timers.erase(pTimer), which does a find() internally. Done. https://codereview.chromium.org/2251333002/diff/1/fpdfsdk/javascript/app.h File fpdfsdk/javascript/app.h (right): https://codereview.chromium.org/2251333002/diff/1/fpdfsdk/javascript/app.h#ne... fpdfsdk/javascript/app.h:11: #include <vector> On 2016/08/18 06:16:19, Lei Zhang wrote: > IWYU Done.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
lgtm
The CQ bit was checked by dsinclair@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== Use a map for app::m_Timers Currently the timers is a vector. When we cancel a timer we have an O(n) operation to remove the timer. If there are a lot of timers (which this test has > 16k) this can take a long time. The impact is a lot lower in Release, but the test is very slow in Debug. From Linux on waterfall: [ RUN ] FPDFFormFillEmbeddertest.BUG_634716 [ OK ] FPDFFormFillEmbeddertest.BUG_634716 (7855 ms) From Linux try bot: [ RUN ] FPDFFormFillEmbeddertest.BUG_634716 [ OK ] FPDFFormFillEmbeddertest.BUG_634716 (431 ms) From Linux XFA Rel GYP on waterfall: [ RUN ] FPDFFormFillEmbeddertest.BUG_634716 [ OK ] FPDFFormFillEmbeddertest.BUG_634716 (185 ms) From Linux XFA Rel GYP try bot: [ RUN ] FPDFFormFillEmbeddertest.BUG_634716 [ OK ] FPDFFormFillEmbeddertest.BUG_634716 (72 ms) ========== to ========== Use a map for app::m_Timers Currently the timers is a vector. When we cancel a timer we have an O(n) operation to remove the timer. If there are a lot of timers (which this test has > 16k) this can take a long time. The impact is a lot lower in Release, but the test is very slow in Debug. From Linux on waterfall: [ RUN ] FPDFFormFillEmbeddertest.BUG_634716 [ OK ] FPDFFormFillEmbeddertest.BUG_634716 (7855 ms) From Linux try bot: [ RUN ] FPDFFormFillEmbeddertest.BUG_634716 [ OK ] FPDFFormFillEmbeddertest.BUG_634716 (431 ms) From Linux XFA Rel GYP on waterfall: [ RUN ] FPDFFormFillEmbeddertest.BUG_634716 [ OK ] FPDFFormFillEmbeddertest.BUG_634716 (185 ms) From Linux XFA Rel GYP try bot: [ RUN ] FPDFFormFillEmbeddertest.BUG_634716 [ OK ] FPDFFormFillEmbeddertest.BUG_634716 (72 ms) Committed: https://pdfium.googlesource.com/pdfium/+/2eb7c7dd6392488d858989da8d57d618f58f... ==========
Message was sent while issue was closed.
Committed patchset #2 (id:20001) as https://pdfium.googlesource.com/pdfium/+/2eb7c7dd6392488d858989da8d57d618f58f...
Message was sent while issue was closed.
https://codereview.chromium.org/2251333002/diff/20001/fpdfsdk/javascript/app.cpp File fpdfsdk/javascript/app.cpp (right): https://codereview.chromium.org/2251333002/diff/20001/fpdfsdk/javascript/app.... fpdfsdk/javascript/app.cpp:553: m_Timers[timerRef] = std::move(timer); This feels strange, mapping a pointer to itself, Why isn't this just std::set<std::unique_ptr<GlobalTimer> > ???
Message was sent while issue was closed.
On 2016/08/18 17:17:43, Tom Sepez wrote: > https://codereview.chromium.org/2251333002/diff/20001/fpdfsdk/javascript/app.cpp > File fpdfsdk/javascript/app.cpp (right): > > https://codereview.chromium.org/2251333002/diff/20001/fpdfsdk/javascript/app.... > fpdfsdk/javascript/app.cpp:553: m_Timers[timerRef] = std::move(timer); > This feels strange, mapping a pointer to itself, Why isn't this just > std::set<std::unique_ptr<GlobalTimer> > ??? I already asked the same question.
Message was sent while issue was closed.
https://codereview.chromium.org/2251333002/diff/20001/fpdfsdk/javascript/app.cpp File fpdfsdk/javascript/app.cpp (right): https://codereview.chromium.org/2251333002/diff/20001/fpdfsdk/javascript/app.... fpdfsdk/javascript/app.cpp:553: m_Timers[timerRef] = std::move(timer); On 2016/08/18 17:17:43, Tom Sepez wrote: > This feels strange, mapping a pointer to itself, Why isn't this just > std::set<std::unique_ptr<GlobalTimer> > ??? If this was a set I'd have the same issue as before in that it would be a linear search to find the GlobalTimer* in the remove method. I need the key to be the pointer, but we want the unique_ptr for the memory cleanup happy-ness. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
