Ticket #448 (reopened defect)

Opened 2 years ago

Last modified 16 months ago

Eraser 6.1.0.2779 Crash Assistant very slow compressing crash reports

Reported by: phkhgh Owned by: Garrett
Priority: major Milestone: Eraser 6.1/6.2
Component: BlackBox Version:
Keywords: Crash Assistant, crash reports, compression Cc:
Processor Architecture: x64 (64-bit) Blocked By:
Blocking: Operating System: Windows Vista

Description

I'm fairly sure I now have a good, working install of r2779.
When open the Crash Assistant & click "check for solutions," it starts compressing crash files. This process (on a Q9400, 8 GB RAM machine) takes ~ 15 - 20 min to compress.

Appears can user Eraser while Crash Assistant is running / compressing, but if you need to close / reboot system or close Eraser, the compressing time is a problem. Any decent archiver would compress same size files at max setting in < 2 min.

When it crashes & restart Eraser, presents a balloon by systray.
Open Crash Assistant & main button now says, "Check for Solutions."

Are there actually solutions to check for? Appears it just starts compressing crash files. If so, button should say, "Send Reports."

If there is a means ??? to check for solution, maybe need a 2nd button - one for Send, 1 for Check Solutions.

Change History

comment:1 Changed 2 years ago by phkhgh

Also, as compression of crash reports reaches ~ 60%, compression rate slows to a crawl.

comment:2 Changed 2 years ago by Joel

  • Milestone set to Eraser 6.1/6.2

comment:3 Changed 2 years ago by Joel

I have tweaked the code a little in r2789 and I now have a compressed report in about 1 minute and 45 seconds. It won't be as fast as 7-zip because 7-zip's written in C++ but the library I'm using is a managed port.

For the record, 7-zip managed to compress the report in about 30 seconds on my computer.

comment:4 Changed 2 years ago by Joel

For the second part of your query, I intend for Check For Solutions to be a feedback mechanism, like Windows' Error Reporting. That's currently unimplemented so the workflow is a little weird. But I'm working on it.

comment:5 Changed 2 years ago by Joel

  • Status changed from new to closed
  • Owner set to Joel
  • Resolution set to fixed

comment:6 Changed 20 months ago by phkhgh

Appears to not be fixed - in 6.1.0.2804. In last crash report sent (~ Nov 2012), compressing & sending crash report still took easily 15 min - probably much more - gave up watching it.

Send report process doesn't take excessive RAM - process is just very slow. My machine has ~ 5 GB FREE RAM; Q9400 CPU; few other apps running while sending crash reports.

comment:7 Changed 20 months ago by phkhgh

  • Status changed from closed to reopened
  • Resolution fixed deleted

Please reopen. Still same problem as reported earlier in 6.1.0.2804, on Vista hm prem SP2.
Compressing crash reports takes > 15 - 20 min. Plenty of free RAM (> 5 GB) & plenty of free CPU resources. Perhaps something is interfering - but there's no problem compressing large files in very little time, using 7Zip or WinRAR.

If it is transferring data as the file is being compressed, perhaps it's a server issue. Otherwise, my computer is normally super fast at these type tasks.

Interface dialog should be changed as earlier noted. It's confusing / misleading.

comment:8 Changed 18 months ago by Garrett

  • Owner changed from Joel to Garrett
  • Status changed from reopened to closed
  • Resolution set to wontfix

This is an environmental issue, closed for now

comment:9 Changed 16 months ago by Joel

  • Status changed from closed to reopened
  • Resolution wontfix deleted
Note: See TracTickets for help on using tickets.