sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: deno
Issue: Poor Headers performance
Labels: perf,web

Iterating `Headers` is extremely slow compared to a `Map`. Other ops are slow too, but iteration appears to be among the worst. Related #19861 

```
benchmark      time (avg)        iter/s             (min … max)       p75       p99      p995
--------------------------------------------------------------- -----------------------------


headers         5.26 µs/iter     189,956.7     (5.09 µs … 5.55 µs)   5.32 µs   5.55 µs   5.55 µs
map            94.73 ns/iter  10,556,304.4  (88.03 ns … 111.51 ns)  96.83 ns 103.83 ns 109.25 ns

summary
  map
   55.57x faster than headers
```

Benchmark code:
```ts
function generateRandomString(length: number) {
  let result = '';
  for (let i = 0; i < length; i++) {
      const randomCode = Math.floor(Math.random() * (127 - 32) + 32);
      result += String.fromCharCode(randomCode);
  }
  return result;
}

function calcHeadersLength(headers: Map<string, string>|Headers) {
    let length = 0;
    for (const [k, v] of headers) {
      length += k.length + v.length + 2;
    }
    return length;
}

const N = 8;

const headers = new Headers();
for (let i = 0; i < N; i++)
  headers.set(String.fromCharCode(65 + i), generateRandomString(1024));

const map = new Map();
for (let i = 0; i < N; i++)
  map.set(String.fromCharCode(65 + i), generateRandomString(1024));

Deno.bench("headers", { group: "iter" }, () =>{
  calcHeadersLength(headers);
});

Deno.bench("map", { group: "iter" }, () =>{
  calcHeadersLength(map);
});
```
Repository: godot
Issue: `Camera3D.project_ray_origin` does not place the ray origin on the near plane when in perspective mode
Labels: discussion,documentation,topic:3d

### Godot version

v4.2.beta.custom_build [06d518916] (latest master)

### System information

Godot v4.2.beta (06d518916) - Windows 10.0.22621 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3050 Laptop GPU (NVIDIA; 31.0.15.3598) - 11th Gen Intel(R) Core(TM) i5-11400H @ 2.70GHz (12 Threads)

### Issue description

When a Camera3D node is set to perspective projection mode, I expected `Camera3D.project_ray_origin` to place the ray origin on the camera's near plane. But in reality it always returns the camera's origin. In comparison, in the case of orthographic projection, the ray origin is correctly placed on the camera's near plane.

The code causing this bug can be found in [Camera3D.cpp](https://github.com/godotengine/godot/blob/06d51891678e3abf360d6fcd2e8bd1ba96704fcc/scene/3d/camera_3d.cpp#L345), where it always returns the camera's origin for non-orthographic projections.

### Steps to reproduce

1. Create a Camera3D node and place it in any 3D scene.
2. Add a built-in script on the Camera, and put the following test code inside:
```gdscript
func _ready():
	global_position = Vector3(0, 0, 0)
	global_rotation = Vector3(0, 0, 0)
	set_orthogonal(5.0, 0.5, 1000.0)
	# Prints -0.5, on the near plane as expected.
	print("Orthogonal ray origin: " + str(project_ray_origin(Vector2(200, 200)).z))
	set_perspective(75.0, 0.5, 1000.0)
	# Prints 0 instead, which is the camera origin's Z position and not the near plane.
	print("Perspective ray origin: " + str(project_ray_origin(Vector2(200, 200)).z))
```
3. Run the 3D scene and observe the output.

### Minimal reproduction project

N/A
Repository: pytorch
Issue: pyTorch 2.1 3x slower than 2.0
Labels: module: performance,module: windows,module: cuda,triaged

### 🐛 Describe the bug

When I run my old semantic segmentation network using pyTorch 2.1 (with both CUDA 11.8 and 12.1) python 3.11 on windows with two Titan RTX cards, using wider Resnet everything is 3x slower then when I run it using pythorch 2.0. 

Have not tried any of the other nets (Resnet, efficientnet ...)  

in training each iteration takes 3 seconds vs 1 second in pyTorch 2.0


### Versions

Collecting environment information...
PyTorch version: 2.1.0
Is debug build: False
CUDA used to build PyTorch: 12.1
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 11 Enterprise
GCC version: Could not collect
Clang version: Could not collect
CMake version: version 3.24.2
Libc version: N/A

Python version: 3.11.5 | packaged by Anaconda, Inc. | (main, Sep 11 2023, 13:26:23) [MSC v.1916 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.22621-SP0
Is CUDA available: True
CUDA runtime version: 12.1.66
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration:
GPU 0: NVIDIA TITAN RTX
GPU 1: NVIDIA TITAN RTX

Nvidia driver version: 537.58
cuDNN version: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.1\bin\cudnn_ops_train64_8.dll
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture=9
CurrentClockSpeed=4501
DeviceID=CPU0
Family=107
L2CacheSize=16384
L2CacheSpeed=
Manufacturer=AuthenticAMD
MaxClockSpeed=4501
Name=AMD Ryzen 9 7950X 16-Core Processor
ProcessorType=3
Revision=24834

Versions of relevant libraries:
[pip3] numpy==1.26.0
[pip3] torch==2.1.0
[pip3] torchaudio==2.1.0
[pip3] torchvision==0.16.0
[conda] blas                      1.0                         mkl
[conda] mkl                       2023.1.0         h6b88ed4_46357
[conda] mkl-service               2.4.0           py311h2bbff1b_1
[conda] mkl_fft                   1.3.8           py311h2bbff1b_0
[conda] mkl_random                1.2.4           py311h59b6b97_0
[conda] numpy                     1.26.0          py311hdab7c0b_0
[conda] numpy-base                1.26.0          py311hd01c5d8_0
[conda] pytorch                   2.1.0           py3.11_cuda12.1_cudnn8_0    pytorch
[conda] pytorch-cuda              12.1                 hde6ce7c_5    pytorch
[conda] pytorch-mutex             1.0                        cuda    pytorch
[conda] torchaudio                2.1.0                    pypi_0    pypi
[conda] torchvision               0.16.0                   pypi_0    pypi

cc @peterjc123 @mszhanyi @skyline75489 @nbcsm @vladimir-aubrecht @iremyux @Blackhex @cristianPanaite @ptrblck
Repository: pytorch
Issue: FSDP load sharded state dict + multi-backend init + bf16 + gloo (?) crashes
Labels: high priority,triage review,oncall: distributed,module: fsdp

### 🐛 Describe the bug

I am initializing process groups as follows:

```
dist.init_process_group("cpu:gloo,cuda:nccl", timeout=timedelta(seconds=300))
```

and loading in a 70B model using ShardedStateDict and a state_dict w/bf16 model parameters. 

When only "nccl" is used for init, this works fine, but it appears when Gloo is used, Gloo backend gets chosen over NCCL in some all_gather calls (specifically in _sharded_pre_load_state_dict_hook). This results in a crash because Gloo doesn't support bf16 data dtype.

2 open questions:

1. Why does the selected backend differ based on the init_process_group backend specification? Since the tensor types don't change, I'd expect the same backend to be used. 
2. Should gloo support bf16 datatype? 

The context is that I'd like to be able to load in bf16 state_dicts.

### Versions

main

cc @ezyang @gchanan @zou3519 @kadeng @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin
Repository: deno
Issue: Poor URLSearchParams performance for certain values
Labels: perf,web,ext/url

`URLSearchParams` is outperformed 10x by a polyfill for certain query strings.

E.g. `x=[[43,87],[15,48],[96,83],[87,84],[91,56],[14,42],[17,75],[79,19],[12,46],[31,84],[57,58],[23,30],[80,19],[76,33],[7,19],[66,96],[77,97],[83,48],[76,63],[79,90],[68,9],[81,22],[77,81],[23,18],[70,53],[70,95],[38,62],[49,74],[95,79],[41,99],[30,65],[38,49],[55,63],[1,3],[88,25],[98,81],[99,50],[45,90],[14,99],[11,19],[32,33],[71,89],[60,48],[85,26],[22,5],[43,55],[56,27],[96,78],[5,71],[31,34],[43,71],[99,60],[87,66],[84,90],[77,2],[83,24],[50,91],[92,63],[26,45],[0,39],[57,31],[94,34],[57,81],[24,85],[58,24],[68,22],[86,77],[65,6],[3,47],[67,71],[8,69],[44,40],[21,58],[96,43],[29,70],[89,3],[86,58],[37,90],[76,34],[38,20],[49,86],[32,3],[68,21],[14,75],[26,61],[7,73],[3,78],[57,13],[8,90],[31,4],[66,36],[98,94],[12,63],[49,82],[80,77],[17,69],[10,15],[89,75],[28,81],[96,62]]`


```
benchmark      time (avg)        iter/s             (min … max)       p75       p99      p995
--------------------------------------------------------------- -----------------------------


original        8.28 µs/iter     120,831.3   (7.29 µs … 306.08 µs)   7.79 µs  16.58 µs  20.17 µs
polyfill      835.15 ns/iter   1,197,394.3 (797.09 ns … 887.42 ns) 847.56 ns 887.42 ns 887.42 ns

summary
  polyfill
   9.91x faster than original
```

Benchmark code:

```ts
const URLSearchParamsOriginal = globalThis.URLSearchParams;
Object.defineProperty(globalThis, "URLSearchParams", { value: undefined });
await import("npm:url-search-params-polyfill");
const URLSearchParamsPolyfill = globalThis.URLSearchParams;

const randomTuple = () => [(Math.random() * 100)|0, (Math.random() * 100)|0]
const randomArray = Array.from({ length: 100}, randomTuple)

const query = `x=${JSON.stringify(randomArray)}`
console.log(query)

Deno.bench("original", { group: "url" }, () => {
  new URLSearchParamsOriginal(query);
});

Deno.bench("polyfill", { group: "url" }, () => {
  new URLSearchParamsPolyfill(query);
});
```
Repository: vscode
Issue: Specific inputs cause replacing single instance in Search View to skip selection past the next instance
Labels: bug,search,confirmed

<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->

I searched for open issue tickets with the "bug" and "search-replace" labels and didn't find a matching one.

Does this issue occur when all extensions are disabled?: Yes

- VS Code + OS Version Version:
  - VS Code 1.83.1 Snap on Ubuntu 22.04.2
  - VS Code 1.84.0 Insiders Snap on Ubuntu 22.04.2

Steps to Reproduce (adapted / quoting from the repro laid out by [Vectornaut](https://stackoverflow.com/users/1644283/vectornaut) in [their SO question](https://stackoverflow.com/q/77362477/11107541)):

1. Launch VS Code.
2. Reload VS Code with extensions disabled.
3. Use *New Text File* to open a blank editor.
4. Paste the following text into the editor (courtesy of [loremipsum.io](https://loremipsum.io/)).

   ```text
   Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
   ```

5. Click the magnifying glass on the sidebar (or press Ctrl+Shift+F) to open the search view.
6. Enter `dolor` in the *Search* field.
7. Enter `domo` in the *Replace* field.

   The choice of replacement text matters. Using `-----` or `d---r` as the replacement text, for instance, leads to the expected behavior.

8. Select the first search result ("Lorem ipsum **dolor** sit amet").
9. Press Ctrl+Shift+1 twice.
10. ***Expected document state:*** the first two occurrences of `dolor` have been replaced.

    `Lorem ipsum domo sit amet,` ... `labore et domoe magna aliqua.` ... `Duis aute irure dolor in reprehenderit` ...

    ***Actual document state:*** the first and third occurrences of `dolor` have been replaced.

    `Lorem ipsum domo sit amet,` ... `labore et dolore magna aliqua.` ... `Duis aute irure domo in reprehenderit` ...

For the specific repro above, it doesn't seem to matter whether regex mode or case-matching are enabled/disabled.

Additionally, if you just use the button to do the instance replacement (the one bound to `ctrl+shift+1`), you'll observe that instead of the next instance being selected, the next _next_ instance is selected.

I have yet to find out what exactly the input conditions are to illicit this type of behaviour.
Repository: PowerToys
Issue: Customize alt+tab window titles
Labels: Idea-New PowerToy,Needs-Triage

### Description of the new feature / enhancement

This is an issue that's especially frustrating with vscode: with multiple vscode instances open, using alt+tab to find the one you want to switch to is a total guessing game a lot of the time - certainly not intuitive, at least. The issue is that the alt+tab title for vscode windows is the current open file in the instance.. these are often quite generic and not unique between applications/repos you might have open.
What would be a big improvement is if the alt+tab could instead show the name of the open folder in vscode (basically what vscode itself shows on the top of vscode).

### Scenario when this would be used?

Alt+tabbing when you have multiple instances of the same application open.

### Supporting information

Just want to say that there maybe be better solutions for fixing this multitasking/application-switching issue, so I'm open for anything, but afaik PowerToys doesn't have anything for it as of today. PowerToys Run allows you to also search through open applications, but it's not that quick when you have to search + results also show regular results (no way to only show open windows results).
Repository: stable-diffusion-webui
Issue: A bit more faster model loading
Labels: bug-report

Greetings!

i remember early versions of the app i had to wait 15 min for the model to load, but now almost 5 min! it came a long way and i love it, that is great but i think it has a bit more room for optimize as in comfyui it takes 2 min for me to load the model, i don't have a nvidia gpu and i have only 6gb ram on my laptop, it will be great if it loads like comfyui someday, i bet lots of people will get benefit from it. otherwise this is the best webui out there! thanks for all ur hard work

[not a bug really, please change the label if u need to]

kind regards
Repository: vscode
Issue: Caret rounded corners
Labels: under-discussion,editor-theming

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

Recently some platforms have adopted the rounded corners for the caret. And I have to say they look nice. Since everything can be customized about vscode and its caret, why not having the option of rounded corner carets?

![](https://github.com/microsoft/vscode/assets/2157285/0b076d31-6909-42e9-ada9-7542b7a7ac1c)
Repository: storybook
Issue: [Bug]: Typescript auto-generated controls behaves weird
Labels: bug,good first issue,help wanted,typescript,argtypes,sev:S3

### Describe the bug

Auto generating controls only works if there is a tsconfig.json in the root directory.
I started fresh with storybook 7.5 and have a very small monorepo with only one component.

In my root directory I have a tsconfig.base.json and in my components tsconfig.json I extend that via 
```json
{
  "extends": ["../../../tsconfig.base.json"]
}
```

Storybook doesn't seem to pick it up tough and it's not even logging or erroring in any way that something is missing.
The controls just stay empty.

My main.ts:
```ts
import { StorybookConfig } from "@storybook/react-vite";

const config: StorybookConfig = {
  stories: ["../src/**/*.mdx", "../src/**/*.stories.@(js|jsx|mjs|ts|tsx)"],
  addons: [
    "@storybook/addon-links",
    "@storybook/addon-essentials",
    "@storybook/addon-onboarding",
    "@storybook/addon-interactions",
  ],
  framework: {
    name: "@storybook/react-vite",
    options: {},
  },
  docs: {
    autodocs: "tag",
  },
  typescript: {
    reactDocgen: "react-docgen-typescript",
    reactDocgenTypescriptOptions: {},
  },
};

export default config;
```

Initially I had reactDocgenTypescriptOptions filled with the example from https://storybook.js.org/docs/react/configure/typescript but that didn't do anything. The propFilter callback wasn't even called.

By mere chance I realized having a tsconfig.json in my root directory triggered a reload and my props were shown in the Controls panel.

I think Storybook should warn the user that no tsconfig file was found/used when the typescript option is added in the config like above. 

**The typescript config example also includes "compilerOptions" so at first I assumed a tsconfig.json file is not needed.** But those didn't work either and had no effect.

### To Reproduce

https://stackblitz.com/edit/github-b3yb1v?file=.storybook%2Fmain.ts

### System

```bash
Storybook Environment Info:

  System:
    OS: Linux 5.15 Ubuntu 20.04.6 LTS (Focal Fossa)
    CPU: (32) x64 AMD Ryzen 9 5950X 16-Core Processor
    Shell: 5.8 - /usr/bin/zsh
  Binaries:
    Node: 18.15.0 - ~/.nvm/versions/node/v18.15.0/bin/node
    Yarn: 1.22.19 - ~/.local/share/pnpm/yarn
    npm: 9.5.0 - ~/.nvm/versions/node/v18.15.0/bin/npm
    pnpm: 8.7.6 - ~/.local/share/pnpm/pnpm <----- active
  npmPackages:
    @storybook/addon-essentials: ^7.5.1 => 7.5.1
    @storybook/addon-interactions: ^7.5.1 => 7.5.1
    @storybook/addon-links: ^7.5.1 => 7.5.1
    @storybook/addon-onboarding: ^1.0.8 => 1.0.8
    @storybook/blocks: ^7.5.1 => 7.5.1
    @storybook/react: ^7.5.1 => 7.5.1
    @storybook/react-vite: ^7.5.1 => 7.5.1
    @storybook/testing-library: ^0.2.2 => 0.2.2
    eslint-plugin-storybook: ^0.6.15 => 0.6.15
    storybook: ^7.5.1 => 7.5.1
```


### Additional context

_No response_
Repository: next.js
Issue: Edge runtime breaks revalidateTag on Vercel
Labels: bug,Pages Router

### Link to the code that reproduces this issue

https://github.com/matthewwilson/nextjs-boilerplate

### To Reproduce

1. Deploy the application to Vercel. 

It consists of 3 pages
- Home Page (static)
- Child Page (static)
- Edge Page (edge)

All pages make the same API call. 

2. During the build process observe the outputted timestamps returned from the API

A healthy output should look like this:

```
Got timestamp 1698315066.387
Got timestamp 1698315066.387
Got timestamp 1698315066.387
Got timestamp 1698315066.387
```

In this scenario everything will revalidate as expected by POSTing to the revalidate endpoint (/api/revalidate). 


This is unhealthy output:

```
Got timestamp 1698315066.387
Got timestamp 1698315066.387
Got timestamp 1698315070.085
Got timestamp 1698315070.09
```

As soon as we start getting different timestamps (meaning that the API call isn't being memoized/cached) then revalidateTag will only revalidate one of the pages (home or child). No matter how many times revalidateTag is called, only one page will update. 



### Current vs. Expected behavior

I expect revalidateTag to work reliably when revalidating an API call that is used across multiple pages.

The sample app here is a simple reproduction, but we are seeing this same issue in production.

Removing the edge page fixes the issue. But this is not an option for us. 

Everything works when running locally, but breaks on Vercel.

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 22.6.0: Fri Sep 15 13:41:28 PDT 2023; root:xnu-8796.141.3.700.8~1/RELEASE_ARM64_T6000
Binaries:
  Node: 18.18.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.8.0
Relevant Packages:
  next: 13.5.7-canary.35
  eslint-config-next: 13.5.4
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.2.2
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Data fetching (gS(S)P, getInitialProps)

### Additional context

This issue has existed across multiple Next.js versions. 

We have tested it from 13.4.13 to 13.5.7-canary.35
Repository: rust
Issue: return_position_impl_trait_in_trait can not express static lifetime bound
Labels: T-compiler,A-impl-trait,C-bug,T-types,F-return_position_impl_trait_in_trait

### Code

I tried this code:

```rust
pub trait Test {
  fn log(&self);
}

struct A;
impl Test for A {
  fn log(&self) {
    todo!()
  }
}


pub trait MakeTest {
  fn make(&self) -> impl Test + 'static;
}

struct MakeTestA;

impl MakeTest for MakeTestA {
  fn make(&self) -> impl Test + 'static {
    A
  }
}

fn test(maker: impl MakeTest) -> impl Test + 'static {
  maker.make()
}
```

I expected to see this happen: compiled successfully

Instead, this happened: compiled with error

```
error[E0597]: `maker` does not live long enough
  --> src/lib.rs:26:3
   |
25 | fn test(maker: impl MakeTest) -> impl Test + 'static {
   |         ----- binding `maker` declared here
26 |   maker.make()
   |   ^^^^^-------
   |   |
   |   borrowed value does not live long enough
   |   argument requires that `maker` is borrowed for `'static`
27 | }
   | - `maker` dropped here while still borrowed

error[E0310]: the parameter type `impl MakeTest` may not live long enough
  --> src/lib.rs:26:3
   |
26 |   maker.make()
   |   ^^^^^^^^^^^^
   |   |
   |   the parameter type `impl MakeTest` must be valid for the static lifetime...
   |   ...so that the type `impl MakeTest` will meet its required lifetime bounds
   |
help: consider adding an explicit lifetime bound
   |
25 | fn test(maker: impl MakeTest + 'static) -> impl Test + 'static {
   |                              +++++++++

Some errors have detailed explanations: E0310, E0597.
For more information about an error, try `rustc --explain E0310`.
```

### Version it worked on

It worked on nightly-2023-06-12 (at least, not the most recent one).

### Version with regression

I'm testing in recent nightly  2023-10-21

### Other info

I'm updating my project's nightly version and find it not work. I'm not sure if it's a real regression or if the return_position_impl_trait_in_trait's design has been changed.

Intuitively, I thought the above example should as the same as this one which works fine:

```rust
pub trait Test {
  fn log(&self);
}

struct A;
impl Test for A {
  fn log(&self) {
    todo!()
  }
}

pub trait MakeTest {
  type Test: Test + 'static;
  fn make(&self) -> Self::Test;
}

struct MakeTestA;

impl MakeTest for MakeTestA {
  type Test = A;

  fn make(&self) -> Self::Test {
    A
  }
}

fn test(maker: impl MakeTest) -> impl Test + 'static {
  maker.make()
}

```