aboutsummaryrefslogtreecommitdiffhomepage
path: root/tests/OnceTest.cpp
Commit message (Collapse)AuthorAge
* 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-27 12:26:22 +0000