restructure results

1 files changed, 27 insertions, 0 deletions

diff --git a/results/classifier/deepseek-r1:14b/reasoning/performance/2565 b/results/classifier/deepseek-r1:14b/reasoning/performance/2565
new file mode 100644
index 000000000..06f7e0811
--- /dev/null
+++ b/results/classifier/deepseek-r1:14b/reasoning/performance/2565
@@ -0,0 +1,27 @@
+<think>
+Okay, so I need to classify this bug report into one of the given categories. Let me read through the problem carefully.
+
+The user mentioned a performance regression after applying a specific patch in QEMU. The issue affects the SDL interface and VirGL, causing a significant drop in glxgears FPS. Moving the mouse makes it worse. They reverted the commit, which fixed the problem on SDL, suggesting that the patch introduced the bug.
+
+Looking at the categories provided: mistranslation, assembly, other, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor.
+
+The key here is the heavy performance regression with 3D graphics. The problem occurs in SDL and VirGL, which are related to graphical rendering. Since it's a performance issue specific to the graphical interface, "performance" seems relevant, but also considering that it's under the graphic category.
+
+However, since the bug directly impacts the frame rate of a graphical application, it's more about how the graphics are being handled rather than general performance. So "graphic" might be more precise. Alternatively, if the performance hit is due to an optimization or code change in rendering, maybe both could apply, but I think "performance" is broader and fits better because it's causing a significant drop in FPS.
+
+Wait, but let me think again. The user explicitly mentions 3D performance with VirGL and SDL, which are related to the graphical output. So maybe "graphic" is more accurate as it's about the graphical subsystem. But sometimes performance issues are categorized under their own section if they're about speed rather than functionality.
+
+Hmm, but looking back at the categories, "performance" is a separate category. Since the main issue here is the drop in performance specifically in the graphics part, I think either could fit. However, since it's a regression in 3D rendering performance, maybe "graphic" would be better because it's tied to how QEMU handles graphical output.
+
+Wait, but the user also mentions that reverting the commit fixes the issue on SDL, implying that the patch introduced an unintended side effect related to rendering. So perhaps it's more about the graphics handling than overall performance. Therefore, "graphic" might be the right category.
+
+But I'm not entirely sure. Let me see the other options. "Performance" is a broader category, but since the problem is in 3D graphics and using VirGL with SDL, which are part of QEMU's graphical capabilities, maybe it's better under "performance" because it affects how quickly the graphics are rendered.
+
+Alternatively, if the issue was about incorrect rendering or visual artifacts, "graphic" would be more appropriate. But since it's a performance regression in rendering speed, "performance" might make sense.
+
+Wait, but looking at the categories again: graphic is listed as one of them, and the problem is indeed related to graphics performance. So perhaps "performance" is a better fit because it's about the speed issue. Or maybe "graphic" since it's tied to the graphical subsystem.
+
+I'm a bit torn here. The user says it's a heavy performance regression with SDL and VirGL. So the performance aspect is critical. Therefore, I think "performance" is the correct category.
+</think>
+
+performance
\ No newline at end of file