aboutsummaryrefslogtreecommitdiffhomepage
path: root/tests/OnceTest.cpp
Commit message (Collapse)AuthorAge
* Modernize and trim down SkOnce.Gravatar mtklein2016-04-18
| | | | | | | | | | | | | | | | | | | | | | | | | | The API and implementation are very much simplified. You may not want to bother reading the diff. As is our trend, SkOnce now uses <atomic> directly. Member initialization means we don't need SK_DECLARE_STATIC_ONCE. SkSpinlock already works this same way. All uses of the old API taking an external bool* and Lock* were pessimal, so I have not carried this sort of API forward. It's simpler, faster, and more space-efficient to always use this single SkOnce class interface. SkOnce weighs 2 bytes: a done bool and an SkSpinlock, also a bool internally. This API refactoring opens up the opportunity to fuse those into a single three-state byte if we'd like. No public API changes. TBR=reed@google.com BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1894893002 Review URL: https://codereview.chromium.org/1894893002
* clean up more dead codeGravatar mtklein2016-02-16
| | | | | | | | | | - SkSHA1 is unused - SkRunnable is obsolete now that we have std::function BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1705583003 Review URL: https://codereview.chromium.org/1705583003
* If we swap its arguments, SkTaskGroup::batch() _is_ sk_parallel_for.Gravatar mtklein2016-01-04
| | | | | | | | | | | Why have two names if we can get away with one? This kills off sk_parallel_for_thread_count(), which was only used to avoid forcing a deadlock in OncePtrTest on multicore machines in singlethreaded mode... a really niche use case. Instead just don't explicitly force a race. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1552093002 Review URL: https://codereview.chromium.org/1552093002
* Add sk_parallel_for()Gravatar mtklein2015-06-17
| | | | | | | | | | | | | | | | | | | | | | | | This should be a drop-in replacement for most for-loops to make them run in parallel: for (int i = 0; i < N; i++) { code... } ~~~> sk_parallel_for(N, [&](int i) { code... }); This is just syntax sugar over SkTaskGroup to make this use case really easy to write. There's no more overhead that we weren't already forced to add using an interface like batch(), and no extra heap allocations. I've replaced 3 uses of SkTaskGroup with sk_parallel_for: 1) My unit tests for SkOnce. 2) Cary's path fuzzer. 3) SkMultiPictureDraw. Performance should be the same. Please compare left and right for readability. :) BUG=skia: No public API changes. TBR=reed@google.com Review URL: https://codereview.chromium.org/1184373003
* C++11 override should now be supported by all of {bots,Chrome,Android,Mozilla}Gravatar mtklein2015-03-25
| | | | | | | | | NOPRESUBMIT=true BUG=skia: DOCS_PREVIEW= https://skia.org/?cl=1037793002 Review URL: https://codereview.chromium.org/1037793002
* namespace {} trick for SK_DECLARE_STATIC_ONCEGravatar mtklein2015-01-13
| | | | | | | | | | | | | | | Like all our other SK_DECLARE_STATIC_*, it's usually not a thread-safe thing to put inside a function. Adding namespace {} prevents that syntactically. Needs https://codereview.chromium.org/841263004/ to land first. BUG=chromium:447890 No public API changes. TBR=reed@google.com Review URL: https://codereview.chromium.org/806473006
* Fix up all the easy virtual ... SK_OVERRIDE cases.Gravatar mtklein2015-01-09
| | | | | | | | | | | | This fixes every case where virtual and SK_OVERRIDE were on the same line, which should be the bulk of cases. We'll have to manually clean up the rest over time unless I level up in regexes. for f in (find . -type f); perl -p -i -e 's/virtual (.*)SK_OVERRIDE/\1SK_OVERRIDE/g' $f; end BUG=skia: Review URL: https://codereview.chromium.org/806653007
* MultiPictureDraw is taskgroup aware.Gravatar reed2014-10-29
| | | | | | | | SampleApp is multipicturedraw aware. BUG=skia: Review URL: https://codereview.chromium.org/684923002
* SkLazyPtr suitable as a local or class member.Gravatar mtklein2014-10-20
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/653183006
* SkThreadPool ~~> SkTaskGroupGravatar mtklein2014-09-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkTaskGroup is like SkThreadPool except the threads stay in one global pool. Each SkTaskGroup itself is tiny (4 bytes) and its wait() method applies only to tasks add()ed to that instance, not the whole thread pool. This means we don't need to bring up new thread pools when tests themselves want to use multithreading (e.g. pathops, quilt). We just create a new SkTaskGroup and wait for that to complete. This should be more efficient, and allow us to expand where we use threads to really latency sensitive places. E.g. we can probably now use these in nanobench for CPU .skp rendering. Now that all threads are sharing the same pool, I think we can remove most of the custom mechanism pathops tests use to control threading. They'll just ride on the global pool with all other tests now. This (temporarily?) removes the GPU multithreading feature from DM, which we don't use. On my desktop, DM runs a little faster (57s -> 55s) in Debug, and a lot faster in Release (36s -> 24s). The bots show speedups of similar proportions, cutting more than a minute off the N4/Release and Win7/Debug runtimes. BUG=skia: Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/531653002
* Revert of SkThreadPool ~~> SkTaskGroup (patchset #4 id:60001 of ↵Gravatar mtklein2014-09-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/531653002/) Reason for revert: Leaks, leaks, leaks. Original issue's description: > SkThreadPool ~~> SkTaskGroup > > SkTaskGroup is like SkThreadPool except the threads stay in > one global pool. Each SkTaskGroup itself is tiny (4 bytes) > and its wait() method applies only to tasks add()ed to that > instance, not the whole thread pool. > > This means we don't need to bring up new thread pools when > tests themselves want to use multithreading (e.g. pathops, > quilt). We just create a new SkTaskGroup and wait for that > to complete. This should be more efficient, and allow us > to expand where we use threads to really latency sensitive > places. E.g. we can probably now use these in nanobench > for CPU .skp rendering. > > Now that all threads are sharing the same pool, I think we > can remove most of the custom mechanism pathops tests use > to control threading. They'll just ride on the global pool > with all other tests now. > > This (temporarily?) removes the GPU multithreading feature > from DM, which we don't use. > > On my desktop, DM runs a little faster (57s -> 55s) in > Debug, and a lot faster in Release (36s -> 24s). The bots > show speedups of similar proportions, cutting more than a > minute off the N4/Release and Win7/Debug runtimes. > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.org TBR=bsalomon@google.com, bungeman@google.com, caryclark@google.com, mtklein@chromium.org, reed@google.com NOTREECHECKS=true NOTRY=true BUG=skia: Author: mtklein@google.com Review URL: https://codereview.chromium.org/533393002
* SkThreadPool ~~> SkTaskGroupGravatar mtklein2014-09-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SkTaskGroup is like SkThreadPool except the threads stay in one global pool. Each SkTaskGroup itself is tiny (4 bytes) and its wait() method applies only to tasks add()ed to that instance, not the whole thread pool. This means we don't need to bring up new thread pools when tests themselves want to use multithreading (e.g. pathops, quilt). We just create a new SkTaskGroup and wait for that to complete. This should be more efficient, and allow us to expand where we use threads to really latency sensitive places. E.g. we can probably now use these in nanobench for CPU .skp rendering. Now that all threads are sharing the same pool, I think we can remove most of the custom mechanism pathops tests use to control threading. They'll just ride on the global pool with all other tests now. This (temporarily?) removes the GPU multithreading feature from DM, which we don't use. On my desktop, DM runs a little faster (57s -> 55s) in Debug, and a lot faster in Release (36s -> 24s). The bots show speedups of similar proportions, cutting more than a minute off the N4/Release and Win7/Debug runtimes. BUG=skia: R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/531653002
* Clean up SkOnce:Gravatar mtklein2014-06-02
| | | | | | | | | | | | | | | | 1 Remove atExit feature: clients can do it just as well as SkOnce can. 2 Remove support for functors: no one but the unit test did that. 3 Remove support for unused non-static SkOnceFlag (no SK_ONCE_INIT). 4 Add SkOnce variants for no-arg functions so we're not forced to pass dummy values all the time. 5 Merge SkSpinlock and SkOnceFlag, making all members private. 6 More notes about memory barriers, adding an acquire load after acquiring the spinlock. BUG=skia: R=bungeman@google.com, mtklein@google.com, reed@google.com Author: mtklein@chromium.org Review URL: https://codereview.chromium.org/302083003
* SkOnce: add option to call another cleanup function once at exit.Gravatar commit-bot@chromium.org2014-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | Use this to clean up empty SkData and SkPathRef. Current leaks: Leaked SkRefCntBase: 40 Leaked SkFlattenable: 32 Leaked SkPixelRef: 32 Leaked SkMallocPixelRef: 32 Leaked SkFontConfigInterface: 1 Leaked SkWeakRefCnt: 1 Leaked SkTypeface: 1 Leaked SkFontMgr: 1 Leaked SkDataTable: 3 Leaked SkImage: 1 Leaked ???: 1 Leaked ???: 1 BUG=skia: R=halcanary@google.com, reed@google.com Author: mtklein@google.com Review URL: https://codereview.chromium.org/132803005 git-svn-id: http://skia.googlecode.com/svn/trunk@13180 2bbb7eff-a529-9590-31e7-b0007b416f81
* Move macros from TestClassDef.h to Test.hGravatar commit-bot@chromium.org2014-01-14
| | | | | | | | | | | | | | Motivation: those macros don't make any sense without the definitions in Test.h. BUG= R=mtklein@google.com Author: halcanary@google.com Review URL: https://codereview.chromium.org/138563004 git-svn-id: http://skia.googlecode.com/svn/trunk@13074 2bbb7eff-a529-9590-31e7-b0007b416f81
* SkOnce: let f be any functor, update commentsGravatar commit-bot@chromium.org2013-12-05
| | | | | | | | | | | BUG= R=bungeman@google.com Author: mtklein@google.com Review URL: https://codereview.chromium.org/104433005 git-svn-id: http://skia.googlecode.com/svn/trunk@12518 2bbb7eff-a529-9590-31e7-b0007b416f81
* SK_ONCE for SkData and SkPathRefGravatar commit-bot@chromium.org2013-10-23
| | | | | | | | | | | | | Adds SK_ONCE_FRIEND, to allow SK_DEF_ONCE code to be friends with a class. This had to go in include/core to be visible to headers there. BUG= R=reed@google.com, bungeman@google.com Author: mtklein@google.com Review URL: https://codereview.chromium.org/26491003 git-svn-id: http://skia.googlecode.com/svn/trunk@11914 2bbb7eff-a529-9590-31e7-b0007b416f81
* Remove unnamed namespace usage from tests.Gravatar commit-bot@chromium.org2013-10-12
| | | | | | | | | | | | | | Skia code prefers static over unnamed namespace. BUG=None TEST=None R=bsalomon@google.com, robertphillips@google.com Author: tfarina@chromium.org Review URL: https://codereview.chromium.org/26962002 git-svn-id: http://skia.googlecode.com/svn/trunk@11747 2bbb7eff-a529-9590-31e7-b0007b416f81
* SkThreadPool: tweak two little things that have been annoying meGravatar commit-bot@chromium.org2013-10-10
| | | | | | | | | | | | | | 1) it's pretty annoying that SkThreadPool doesn't include SkRunnable for us; 2) add wait() so we don't have to keep using SkAutoTDelete/free() to wait for completion. BUG= R=scroggo@google.com, reed@google.com Author: mtklein@google.com Review URL: https://codereview.chromium.org/26470005 git-svn-id: http://skia.googlecode.com/svn/trunk@11711 2bbb7eff-a529-9590-31e7-b0007b416f81
* Sketch of SK_ONCEGravatar mtklein@google.com2013-10-09
BUG= R=bungeman@google.com Review URL: https://codereview.chromium.org/26563002 git-svn-id: http://skia.googlecode.com/svn/trunk@11674 2bbb7eff-a529-9590-31e7-b0007b416f81
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-19 22:05:36 +0000