sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: youtube-dl
Issue: [SoundCloud] Option to limit number of track pages to download
Labels: request

### What is the purpose of your *issue*?
- [ ] Bug report (encountered problems with youtube-dl)
- [ ] Site support request (request for adding support for a new site)
- [x] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other

---

I could not find any option to limit the amount of track pages to download when requesting a user page on SoundCloud, and of course this gets rather slow when an account has a massive amount of tracks.

as an example
```python
from __future__ import unicode_literals;
import youtube_dl;

ydl_opts = {
	"playlistend": 2,
	"dateafter": "2016/11/1"
};

with youtube_dl.YoutubeDL(ydl_opts) as ydl:
	results = ydl.extract_info(
		"http://soundcloud.com/anjunabeats",
		download=False
	);
	print(results);
```

```
[soundcloud:user] anjunabeats: Downloading user info
[soundcloud:user] anjunabeats: Downloading track page 1
[soundcloud:user] anjunabeats: Downloading track page 2
[soundcloud:user] anjunabeats: Downloading track page 3
[soundcloud:user] anjunabeats: Downloading track page 4
[soundcloud:user] anjunabeats: Downloading track page 5
[soundcloud:user] anjunabeats: Downloading track page 6
[soundcloud:user] anjunabeats: Downloading track page 7
[soundcloud:user] anjunabeats: Downloading track page 8
[soundcloud:user] anjunabeats: Downloading track page 9
[soundcloud:user] anjunabeats: Downloading track page 10
[soundcloud:user] anjunabeats: Downloading track page 11
[soundcloud:user] anjunabeats: Downloading track page 12
[soundcloud:user] anjunabeats: Downloading track page 13
[soundcloud:user] anjunabeats: Downloading track page 14
[soundcloud:user] anjunabeats: Downloading track page 15
[soundcloud:user] anjunabeats: Downloading track page 16
[soundcloud:user] anjunabeats: Downloading track page 17
[soundcloud:user] anjunabeats: Downloading track page 18
[soundcloud:user] anjunabeats: Downloading track page 19
[soundcloud:user] anjunabeats: Downloading track page 20
[soundcloud:user] anjunabeats: Downloading track page 21
[soundcloud:user] anjunabeats: Downloading track page 22
```
etc., etc.

I just want some way to limit this to 1 page, as an example, also only looking to extract data.
Repository: nvm
Issue: Add the ability to use nvm with 32bit releases as well as 64bit
Labels: installing node,feature requests

It would be really useful if we could use nvm to install 32bit versions of node so that we could make testing quicker.

Perhaps we could pass in a flag to the end like `nvm install 6 -a x86` or something like that?
Repository: TypeScript
Issue: Allow pass through of class-properties
Labels: Bug,Help Wanted,ES Next

**TypeScript Version:**
* 2.2.0-dev.20161113 (Not version specific)
* target = esnext, jsx = preserve

**Description**
I expect Typescript to more or less only strip types but preserve the rest - based on the `target` compilerOption. Especially when using a target like `es2017` or even `esnext`.

Class-properties are always moved into the constructor. This prevents hot-reloading of class-property functions when using [react-hot-loader 3](https://github.com/gaearon/react-hot-loader/tree/next).

Using them is a common pattern for binding event-handler functions to `this` without having to do this for every method in the constructor.

**Code**
```tsx
class MyClass {
  prop1: number = 123;
  handleClick = () => {
    console.log('Click handled');
  }
  render() {
    return <button onClick={this.handleClick}>Click me</button>;
  }
}
```

**Expected emit:**
```jsx
class MyClass {
  prop1 = 123;
  handleClick = () => {
    console.log('Click handled');
  }
  render() {
    return <button onClick={this.handleClick}>Click me</button>;
  }
}
```

**Actual emit:** 

```jsx
class MyClass {
  constructor() {
    super(...arguments);
    this.prop1 = 123;
    this.handleClick = () => {
      console.log('Click handled');
    };
  }
  render() {
    return <button onClick={this.handleClick}>Click me</button>;
  }
}
```
Repository: go
Issue: net: implement closeRead and closeWrite on Plan 9
Labels: OS-Plan9,NeedsInvestigation

We should implement closeRead and closeWrite on Plan 9, so the following tests could be enabled:

- TestCloseRead
- TestCloseWrite
- TestClientWriteShutdown (net/http package, see #7237)
Repository: rust
Issue: E0495 Does not mention the conflicting requirements
Labels: C-enhancement,A-diagnostics,T-compiler

E0495 returns "cannot infer an appropriate lifetime for autoref due to conflicting requirements" and suggest a way to fix this "help: consider using an explicit lifetime parameter..." but it does not say what the conflicting requirements are. This means that if the suggested way to fix it does not work, the user is stuck.
Repository: kubernetes
Issue: hack/update-all takes forever
Labels: priority/important-soon,area/build-release,sig/contributor-experience,lifecycle/frozen

There are about 23 update scripts and it is not obvious which ones have to be run for a given PR. These update scripts take anywhere between 20 - 30 minutes on a beefed up machine. I can't imagine running them on a laptop. 
We need to either
1. Make the script `hack/update-all.sh` be smart and run only the scripts necessary based on the dirty files in a branch, or
2. Optimize the update-* scripts to run faster. 

cc @kubernetes/contributor-experience @thockin @mikedanese @madhusudancs
Repository: go
Issue: cmd/compile: insertVarPhis is very slow
Labels: ToolSpeed,compiler/runtime

go version devel +b687d6a Tue Nov 15 05:35:54 2016 +0000 linux/amd64

My real package takes 30+ seconds to compile.
Using program generator below:

With 500 iterations:
compilation time 0.79s
phiState.insertVarPhis takes 8.27%

With 1000 iterations:
compilation time 1.54s
phiState.insertVarPhis takes 11.84%

With 2000 iterations:
compilation time 3.65s
phiState.insertVarPhis takes 15.75%

With 4000 iterations:
compilation time 10.63s
phiState.insertVarPhis takes 20.94%

With 8000 iterations:
compilation time 26.03s
phiState.insertVarPhis takes 32.16%

With 16000 iterations:
compilation time 101.91s
phiState.insertVarPhis takes 53.08%

```go
package main
func main() {
	println(`package a
type T struct {
	a []*Y
}
type Y struct {
	name string
	i *T
}
var m = make(map[string]*T)
func a() {`)
	for i := 0; i < 16000; i++ {
		println("{ s := m[\"foo\"]")
		println("s.a = append(s.a, &Y{name: \"foo\", i: m[\"foo\"]})")
		println("}")
	}
	println("}")
}
```

insertVarPhis executes inner loop millions of times without doing anything (variable is dead)

compile also consumes 5GB of memory (150KB per statement), which causes compilation on weak VM to never succeed due to OOM kills

Please make it faster and consume less memory.
Repository: youtube-dl
Issue: Function to limit duration and/or size (for livestreams)
Labels: request

### Make sure you are using the *latest* version: run `youtube-dl --version` and ensure your version is *2016.11.14.1*. If it's not read [this FAQ entry](https://github.com/rg3/youtube-dl/blob/master/README.md#how-do-i-update-youtube-dl) and update. Issues with outdated version will be rejected.
- [x] I've **verified** and **I assure** that I'm running youtube-dl **2016.11.14.1**

### Before submitting an *issue* make sure you have:
- [x] At least skimmed through [README](https://github.com/rg3/youtube-dl/blob/master/README.md) and **most notably** [FAQ](https://github.com/rg3/youtube-dl#faq) and [BUGS](https://github.com/rg3/youtube-dl#bugs) sections
- [x] [Searched](https://github.com/rg3/youtube-dl/search?type=Issues) the bugtracker for similar issues including closed ones

### What is the purpose of your *issue*?
- [ ] Bug report (encountered problems with youtube-dl)
- [ ] Site support request (request for adding support for a new site)
- [x] Feature request (request for a new functionality)
- [x] Question
- [ ] Other

---

### The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your *issue*

---

As said in the title youtube-dl is missing any function/parameter to limit the duration and/or the size.
I tried livestreamer before but it did not work at all with the livestream I was recording so I switched to youtube-dl (sorry for that much offtopic). That stream is running 24/7 without any break or so. But they change the title if another content/show starts (e.g. 10min 'news' then 30min 'talk' just a general example). Unfortunately there is also no way to only get audio for a livestream tho I think it should be at least possible to save only audio directly (but still receiving video+audio just drop the video and save only audio). I know there is '-x' but only for postprocessing that means I need to finish a download which will never happen with a 24/7 livestream. It would be nice to have an option to set a limit on the duration but more preferable at least the size.
Let's say we have an option like '--maxdl-filesize SIZE' -> '--maxdl-filesize 10.0m'
this will save the output so far into a file (it's best to use template then to get timecode/length).
I cannot say how difficulty it would be to make a prototype for that (I would do that on my own but I am also in lack of time). The best thing I thought about would be using a script that collects the information about the length of the shows then let it send ctrl-c to stop the download but before that already start a new youtube-dl process since it takes a little time for a new process to start the download. This would not be a perfect solution but a quick'n'dirty one. I haven't tested yet to continuously download the stream and directly use it while downloading in e.g. ffmpeg to split it into parts and as audio only (I am relating to this option --hls-use-mpegts).
Edit: Youtube is using Fragments. Maybe it's possible to start off with those at least.
Repository: opencv
Issue: Check for existence of CUDA driver before calling cuda functions
Labels: feature,priority: low,category: gpu/cuda (contrib)

After fighting for a while with the well-known CUDA error message `CUDA driver version is insufficient for CUDA runtime version`, today I learned that this message will be returned by Nvidia even when there is no driver installed at all, which is totally misleading.

Consider this code

```c++
#include <cuda_runtime.h>
...

  int driverVersion = 0;
  int runtimeVersion = 0;
  cudaError_t error_id;

  error_id = cudaDriverGetVersion(&driverVersion);
  if (error_id != cudaSuccess)
  {
    printf("cudaDriverGetVersion returned %d\n-> %s\n", (int)error_id, cudaGetErrorString(error_id));
    printf("Result = FAIL\n");
    exit(EXIT_FAILURE);
  }
  std::cout << "CUDA driver version: " << driverVersion << std::endl;

  error_id = cudaRuntimeGetVersion(&runtimeVersion);
  if (error_id != cudaSuccess)
  {
    printf("cudaRuntimeGetVersion returned %d\n-> %s\n", (int)error_id, cudaGetErrorString(error_id));
    printf("Result = FAIL\n");
    exit(EXIT_FAILURE);
  }
  std::cout << "CUDA runtime version: " << runtimeVersion << std::endl;
```

When no driver can be found, this code will print:

```
CUDA driver version: 0
cudaRuntimeGetVersion returned 35
-> CUDA driver version is insufficient for CUDA runtime version
Result = FAIL
```

This agrees with the [docs](http://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART____VERSION.html#group__CUDART____VERSION_1g8a06ee14a0551606b7c780084d5564ab):

> If no driver is installed, then 0 is returned as the driver version

--

I propose that all OpenCV Cuda functions (or error handlers) use `cudaDriverGetVersion` to check whether a driver is installed _at all_, and if not, say so, to compensate for the very misleading error message Nvidia is giving us in this case, making you play around with driver versions when in fact any driver you install can't be found at all.

This should save a lot of github issues and stackoverflow questions :)
Repository: opencv
Issue: Second interface function for findCirclesGrid
Labels: feature,category: calib3d

The opencv function findCirclesGrid expects an image as input parameter. The first processing step within the function is to extract a list of points via blobDetector and afterwards the function uses only this list of points. 
For various purposes like searching for the pattern only in part of the image or for iterative refinement it would be very useful to have a second findCirclesGrid function which accents an InputArray containing such list of points instead of an image. 

My suggestion is to put the code starting at https://github.com/opencv/opencv/blob/73e1d64ae07be010a2c64e6906d0e938846c6bef/modules/calib3d/src/calibinit.cpp#L2115 in a second function e.g. findCirclesGridPointList(InputArray _pointList, Size patternSize, OutputArray _centers, int flags)
and let the current findCirclesGrid call this function. The only additional code required is code which converts from the InputArray _pointList to std::vector<Point2f>.

With this splitting one gains a lot of flexibility for a tiny bit of processing overhead.
Repository: vscode
Issue: Simple way to temporarily turn off exclusions for QuickOpen files
Labels: help wanted,feature-request,search,quick-open

Using a transpiled language I sometimes find the need to look at the transpiled code which typically is excluded from QuickOpen. Having a simple way to turn exclusions off would simplify this. Some options come to mind:
- Have a 'Turn Off Exclusions' entry at the end of the results list.
- Have an additional QuickOpen prefix that runs QuickOpen with exclusions turned off.
- Have an option toggle next to the QuickOpen entry field to turn exclusions off.
Repository: opencv
Issue: Build fails WITH_OPENVX=YES if precompiled headers are enabled that is by default
Labels: bug,category: build/install,affected: 3.4

##### System information (version)
- OpenCV => master, 3.1.0-1694-ga19cb20
- Operating System / Platform => Linux-x64, Ubuntu 16.04
- Compiler => gcc-5.4.0 20160609


##### Detailed description

OpenCV build fails if configured to use OpenVX with precompiled headers enabled (that is default).

##### Steps to reproduce

```bash
$ cmake -DOPENVX_ROOT=/home/andreypa/Dev/OpenVX/vx++/_build/install/OpenVX-Linux -DWITH_OPENVX=YES ../opencv
$ make
...
Scanning dependencies of target openvx_hal
[ 25%] Building CXX object 3rdparty/openvx/CMakeFiles/openvx_hal.dir/src/openvx_hal.cpp.o
[ 26%] Linking CXX static library ../lib/libopenvx_hal.a
[ 26%] Built target openvx_hal
Scanning dependencies of target opencv_core_pch_dephelp
[ 26%] Building CXX object modules/core/CMakeFiles/opencv_core_pch_dephelp.dir/opencv_core_pch_dephelp.cxx.o
In file included from /home/andreypa/Dev/OpenCV/opencv-build2/custom_hal.hpp:5:0,
                 from /home/andreypa/Dev/OpenCV/opencv/modules/core/src/hal_replacement.hpp:725,
                 from /home/andreypa/Dev/OpenCV/opencv/modules/core/src/precomp.hpp:89,
                 from /home/andreypa/Dev/OpenCV/opencv-build2/modules/core/opencv_core_pch_dephelp.cxx:1:
/home/andreypa/Dev/OpenCV/opencv/3rdparty/openvx/include/openvx_hal.hpp:5:43: fatal error: opencv2/imgproc/hal/interface.h: No such file or directory
compilation terminated.
```

This can be workarounded by adding `-DENABLE_PRECOMPILED_HEADERS=NO` option to `cmake` though.
Repository: opencv
Issue: Inconsistent convention for cmake option specifying OpenVX location 
Labels: feature,priority: low,category: build/install,affected: 3.4

##### System information (version)
- OpenCV => 3.1.0-1694-ga19cb20
- Operating System / Platform => any
- Compiler => any

##### Detailed description

Currently to specify OpenVX location for cmake the following options are required:
`-DOPENVX_ROOT=/path/to/prebuilt/openvx -DWITH_OPENVX=YES`,
while the more common variable name would be `-DOpenVX_DIR=/path/to/prebuilt/openvx`.
I suggest changing this until people get used to the bad name.
Repository: go
Issue: runtime: aggressive GC completion is disruptive to co-tenants
Labels: Performance,NeedsInvestigation,early-in-cycle

### What version of Go are you using (`go version`)?

go version `devel +1e3c57c Wed Nov 16 20:31:40 2016 +0000` with CL 33093 PS 4 cherry-picked on top, with GOEXPERIMENT=preemptibleloops

### What operating system and processor architecture are you using (`go env`)?

linux/amd64

### What did you do?

I have a program that reads ~1MB records from stdin, decodes the records, and sends UDP datagrams. The program runs with around 20 goroutines. Around 40 copies of the program run on an 8-core host.

### What did you expect to see?

I expected the 95th percentile of mark termination and sweep termination pauses to be 100µs or less.

### What did you see instead?

The program's 95th percentile sweep termination time is around 60ms, and 95th percentile mark termination time is around 30ms. Here's an example gctrace line:

```
gc 11249 @74577.976s 0%: 11+185+35 ms clock, 90+143/358/582+280 ms cpu, 112->114->56 MB, 115 MB goal, 8 P
```

The mark termination pauses are very easy to identify in the execution trace—if this bug needs to be about either sweep term pauses or mark term pauses, let's use it for mark term.

Sweep termination pause distribution:

```
N 10000  sum 115454  mean 11.5454  gmean 0.602555  std dev 22.7221  variance 516.294

     min 0.011
   1%ile 0.014
   5%ile 0.016
  25%ile 0.023
  median 0.34
  75%ile 12
  95%ile 59
  99%ile 107
     max 199

⠀⠀⠀⠀⠀⠀⠰⡄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡖ 0.274
⠀⠀⠀⠀⠀⠀⡂⠄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡇
⠠⠤⠤⠤⠤⠤⠄⠰⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠄⠧ 0.000
⠈⠉⠉⠉⠉⠉⠙⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠙⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠙⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠁
      0                     50                     100
```

Mark termination pause distribution:

```
N 10000  sum 61391.3  mean 6.13913  gmean 0.93492  std dev 12.9254  variance 167.066

     min 0.04
   1%ile 0.053
   5%ile 0.064
  25%ile 0.1
  median 0.82
  75%ile 6.6
  95%ile 29
  99%ile 64
     max 209

⠀⠀⠀⠀⠀⠀⠰⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡖ 0.447
⠀⠀⠀⠀⠀⠀⡁⠄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡇
⠠⠤⠤⠤⠤⠤⠄⠑⠒⠦⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠄⠧ 0.000
⠈⠉⠉⠉⠉⠉⠙⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠋⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠉⠁
      0                                   50
```

And here's the execution trace of a slow mark termination pause, taking over 16ms. Proc 6 organizes the mark termination phase. Procs 1, 2, 3, 4, and 5 execute it quickly at around t=1007ms. Proc 0 does mark termination around t=1014ms, and Proc 7 delays until t=1024ms at which point the global pause concludes.

<img width="1651" alt="screen shot 2016-11-17 at 1 58 11 pm" src="https://cloud.githubusercontent.com/assets/230685/20410040/14b8049c-acd0-11e6-856c-40548a9ca0be.png">
Repository: javascript
Issue: Add high-level theory/guiding principles
Labels: question,editorial

Most people don't have the time or energy to read through the entire style guide and internalize it. Additionally, there are always going to be gaps that we haven't explicitly handled.

For both of these cases, I think it would be nice to add a few concise guiding principles to the document. This would allow people to essentially "memorize these 6 ideas and you will know what to do 99% of the time."

I don't know what these principles are or should be, but I figured I would get the discussion started here.
Repository: gin
Issue: Provide guideline on how to write good middleware
Labels: document

There have been at least a couple of discussions in the past about good error handling strategies in middleware (see #665 and #274). It would be great if the outcome of those discussions would be summarized in the documentation...perhaps under **Custom Middleware** in the README file?
Repository: go
Issue: sync: RWMutex scales poorly with CPU count
Labels: Performance,NeedsFix,compiler/runtime

On a machine with many cores, the performance of `sync.RWMutex.R{Lock,Unlock}` degrades dramatically as `GOMAXPROCS` increases.

This test program:

```go
package benchmarks_test

import (
	"fmt"
	"sync"
	"testing"
)

func BenchmarkRWMutex(b *testing.B) {
	for ng := 1; ng <= 256; ng <<= 2 {
		b.Run(fmt.Sprint(ng), func(b *testing.B) {
			var mu sync.RWMutex
			mu.Lock()

			var wg sync.WaitGroup
			wg.Add(ng)

			n := b.N
			quota := n / ng

			for g := ng; g > 0; g-- {
				if g == 1 {
					quota = n
				}

				go func(quota int) {
					for i := 0; i < quota; i++ {
						mu.RLock()
						mu.RUnlock()
					}
					wg.Done()
				}(quota)

				n -= quota
			}

			if n != 0 {
				b.Fatalf("Incorrect quota assignments: %v remaining", n)
			}

			b.StartTimer()
			mu.Unlock()
			wg.Wait()
			b.StopTimer()
		})
	}
}
```

degrades by a factor of 8x as it saturates threads and cores, presumably due to cache contention on &rw.readerCount:

```
# ./benchmarks.test -test.bench . -test.cpu 1,4,16,64
testing: warning: no tests to run
BenchmarkRWMutex/1      20000000                72.6 ns/op
BenchmarkRWMutex/1-4    20000000                72.4 ns/op
BenchmarkRWMutex/1-16   20000000                72.8 ns/op
BenchmarkRWMutex/1-64   20000000                72.5 ns/op
BenchmarkRWMutex/4      20000000                72.6 ns/op
BenchmarkRWMutex/4-4    20000000               105 ns/op
BenchmarkRWMutex/4-16   10000000               130 ns/op
BenchmarkRWMutex/4-64   20000000               160 ns/op
BenchmarkRWMutex/16     20000000                72.4 ns/op
BenchmarkRWMutex/16-4   10000000               125 ns/op
BenchmarkRWMutex/16-16  10000000               263 ns/op
BenchmarkRWMutex/16-64   5000000               287 ns/op
BenchmarkRWMutex/64     20000000                72.6 ns/op
BenchmarkRWMutex/64-4   10000000               137 ns/op
BenchmarkRWMutex/64-16   5000000               306 ns/op
BenchmarkRWMutex/64-64   3000000               517 ns/op
BenchmarkRWMutex/256                    20000000                72.4 ns/op
BenchmarkRWMutex/256-4                  20000000               137 ns/op
BenchmarkRWMutex/256-16                  5000000               280 ns/op
BenchmarkRWMutex/256-64                  3000000               602 ns/op
PASS
```

A "control" test, calling a no-op function instead of `RWMutex` methods, displays no such degradation: the problem does not appear to be due to runtime scheduling overhead.
Repository: angular
Issue: Allow disabling NgControlStatus
Labels: feature,area: forms,feature: under consideration

**I'm submitting a ...** 
```
[ ] bug report
[x] feature request
[ ] support request
```

**Current behavior**
`NgControlStatus` is applied automatically to any form control/group.

**Expected behavior**
Should be able to opt out of this directive. Maybe as simple as adding a `:not([ngNoControlStatus])` to the selector?

**Minimal reproduction of the problem with instructions**

**What is the motivation / use case for changing the behavior?**
We don't use the default `.ng-xxxxx` status classes, so it'd be nice to disable them (and the associated pointless DOM changes they bring).

**Please tell us about your environment:**

* **Angular version:** 2.1.1 but pretty sure this is the current behavior too.

* **Browser:** all
 
* **Language:** n/a

* **Node (for AoT issues):** n/a