http://bugs.winehq.org/show_bug.cgi?id=21245
Summary: file operations are very slow or hangs solidworks Product: Wine Version: 1.1.35 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 AssignedTo: wine-bugs@winehq.org ReportedBy: denis.bonnenfant@diderot.org CC: madewokherd@gmail.com
Created an attachment (id=25535) --> (http://bugs.winehq.org/attachment.cgi?id=25535) WINEDEBUG=-all,fixme+storage log
File operations are very slow in Solidworks (all versions), and most of the time saving fails, application is hung, and has to be killed from the console with control-c or winserver -k
The issue seems to be related to storage implementation, as the new transacted mode made the things slower and unstable.
WINEDEBUG=-all,+storage generates huge logs, ( 4 Gb in 10 minutes !) just for a 4 Mb file opening, and it doesn't succeed, it has to be killed. Looks like an infinite loop or a race condition...
Attached WINEDEBUG=-all,fixme+storage log for a file open operation. The file save hangs Solidworks, with 100% cpu.
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #1 from denis bonnenfant denis.bonnenfant@diderot.org 2010-01-03 17:20:32 --- Created an attachment (id=25536) --> (http://bugs.winehq.org/attachment.cgi?id=25536) WINEDEBUG=-all,+storage log ( last 10000 lines)
the last lines of +storage log during file open. (it doesn't succeed, I killed the app after 20 minutes and 8 Gb of log).
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #2 from Nikolay Sivov bunglehead@gmail.com 2010-01-06 00:02:44 --- Does reverting commit 8518323e070377c07a3d421573dc3348e28008a4 help?
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #3 from denis bonnenfant denis.bonnenfant@diderot.org 2010-01-10 16:36:24 --- No changes with 1.1.36.
When saving files, solidworks is blocked with 100% cpu usage...
Before freezing, there are still lots of fixmes like these :
fixme:storage:StgCreateDocfile Storage share mode not implemented. fixme:storage:StorageInternalImpl_Commit (0x4d444c0,2): stub
http://bugs.winehq.org/show_bug.cgi?id=21245
denis bonnenfant denis.bonnenfant@diderot.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.35 |1.1.38
--- Comment #4 from denis bonnenfant denis.bonnenfant@diderot.org 2010-02-19 08:50:58 --- I investigated the problem a little bit further, and it seems to be related to file modification operations :
- when saving a new file, it works, - when saving an existing one it fails, application is blocked, 100%CPU, ^C in console stops the operation, and application displays a popup "saving failed", and works nomally ( but nothing has been saved)
http://bugs.winehq.org/show_bug.cgi?id=21245
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.38 |1.1.35
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com 2010-02-19 08:53:54 --- denis, don't change version field please.
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #6 from denis bonnenfant denis.bonnenfant@diderot.org 2010-05-25 08:46:47 --- 1.2-rc1 shows some progresses !
Now it doesn't crashes anymore, but file operation are very, very slow : more than one minute to save a file, all the application is freezed, 100% CPU and 20 lines like this one on the console :
fixme:storage:StorageInternalImpl_Commit (0x11020330,2): stub
But it succeeds, so now the application is useable !
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #7 from denis bonnenfant denis.bonnenfant@diderot.org 2010-05-26 11:53:02 --- Update : saving to a local disk instead of a network mount ( nfs or smb ) is much more faster (but longer than under windows).
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #8 from denis bonnenfant denis.bonnenfant@diderot.org 2010-06-29 08:59:30 --- (In reply to comment #7)
Update : saving to a local disk instead of a network mount ( nfs or smb ) is much more faster (but longer than under windows).
Still an issue with rc5, saving files with WINEDEBUG=+storage falls in endless loop, 10Gb log in one hour, and nothing saved.
Without +storage, saving files works sometimes, but is very very slow...
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #9 from denis bonnenfant denis.bonnenfant@diderot.org 2010-07-07 05:10:40 --- I investigated the problem a little bit further and found that the function SmallBlockChainStream_GetNextBlockInChain called in the first loop in SmallBlockChainStream_WriteAt is responsive : it calls BlockChainStream_ReadAt for reading 4 bytes (Sizeof(DWORD)) at a time, so it is particularly unefficient...
trace:storage:SmallBlockChainStream_WriteAt + trace:storage:SmallBlockChainStream_GetNextBlockInChain --------- trace:storage:BlockChainStream_ReadAt (0x116a2290)-> 7932 0x32d54c 4 0x32d548 trace:storage:BlockChainStream_ReadAt block 2545 trace:storage:ImplBIGBLOCKFILE_ReadAt (0x116a2210)-> 1303804 0x32d54c 4 0x32d4e8 trace:storage:ImplBIGBLOCKFILE_ReadAt page 1, offset 255228, bytes_from_page 4, bytes_left 4 trace:storage:ImplBIGBLOCKFILE_ReadAt finished trace:storage:SmallBlockChainStream_WriteAt + trace:storage:SmallBlockChainStream_GetNextBlockInChain --------- trace:storage:BlockChainStream_ReadAt (0x116a2290)-> 7936 0x32d54c 4 0x32d548 trace:storage:BlockChainStream_ReadAt block 2545 trace:storage:ImplBIGBLOCKFILE_ReadAt (0x116a2210)-> 1303808 0x32d54c 4 0x32d4e8 trace:storage:ImplBIGBLOCKFILE_ReadAt page 1, offset 255232, bytes_from_page 4, bytes_left 4 trace:storage:ImplBIGBLOCKFILE_ReadAt finished
while ( (blockNoInSequence > 0) && (blockIndex != BLOCK_END_OF_CHAIN)) { if(FAILED(SmallBlockChainStream_GetNextBlockInChain(This, blockIndex, &blockIndex))) return STG_E_DOCFILECORRUPT; blockNoInSequence--; }
As this loop seems to be here just to verify data integrity, removing it is harmful, and made huge speed improvement !
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #10 from denis bonnenfant denis.bonnenfant@diderot.org 2010-07-07 08:57:23 --- It is fast, but file gets corrupted... So this loop is useful... It has to be optimized, but i can't see exactly how to do.
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #11 from Vincent Povirk madewokherd@gmail.com 2010-07-07 09:28:22 --- Just be patient for now. I have a lot of performance-related changes that I haven't sent yet. Because they're dangerous changes, I'm going to add them slowly after 1.2 is released.
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #12 from Austin English austinenglish@gmail.com 2010-07-07 12:25:35 --- (In reply to comment #11)
Just be patient for now. I have a lot of performance-related changes that I haven't sent yet. Because they're dangerous changes, I'm going to add them slowly after 1.2 is released.
Would you mind attaching them here, so Denis/others can test them?
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #13 from Vincent Povirk madewokherd@gmail.com 2010-07-07 12:31:00 --- The results of testing them as they are would not be useful.
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #14 from denis bonnenfant denis.bonnenfant@diderot.org 2010-07-31 09:29:14 --- I saw some commits in storage, so I tested 1.3.0, but it is still horribly slow... I hope that optimized version will come soon !
http://bugs.winehq.org/show_bug.cgi?id=21245
Serg Silantyev xren@pisem.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #15 from Serg Silantyev xren@pisem.net 2010-08-03 12:56:39 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #16 from Vincent Povirk madewokherd@gmail.com 2010-08-26 22:05:29 --- 89646084ba281366d69b1cd8fb168d9440cf3569 should fix the worst of the performance issues. Please retest.
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #17 from denis bonnenfant denis.bonnenfant@diderot.org 2010-08-28 15:58:56 CDT --- Ok, it works. There is still a 20-30s lockup for each file saved ( can be very long when saving a big assembly with lots of files ), there is almost no cpu load during the window lockup in normal mode, but WINEDEBUG=+storage, shows a lot of logs during lockup, so I guess that some optimisations are still possible.
But anyway, SolidWorks is now really useable !
Nice job !
http://bugs.winehq.org/show_bug.cgi?id=21245
denis bonnenfant denis.bonnenfant@diderot.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
--- Comment #18 from denis bonnenfant denis.bonnenfant@diderot.org 2010-10-02 17:30:36 CDT --- Big regression, in 1.3.4, Solidworks files can't be saved, nor assemblies opened. There are no errors in console, but SolidWorks displays a popup "invalid file format"
I will run a regression test when I can find some time...
http://bugs.winehq.org/show_bug.cgi?id=21245
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression |
--- Comment #19 from Vincent Povirk madewokherd@gmail.com 2010-10-02 17:33:56 CDT --- File a new bug for that please.
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #20 from denis bonnenfant denis.bonnenfant@diderot.org 2010-10-03 16:49:33 CDT --- Ok, it is in Bug 24615 :
c8a48f237e43174673fa3686ebe99e42f6a0d8a4 is the first bad commit commit c8a48f237e43174673fa3686ebe99e42f6a0d8a4 Author: Vincent Povirk vincent@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #21 from denis bonnenfant denis.bonnenfant@diderot.org 2010-11-10 08:32:11 CST --- Another issue related to this bug, files are growing every time they are saved. For example, a simple assembly containing 3 parts : saved the first time : 1.5 Mb, and after 3 or 4 savings : 13.5 Mb ! saving time is growing exponentially too...
For part files, the problem is less important, but still significant.
Interestingly, opening/saving on windows shrinks the file a little bit.
http://bugs.winehq.org/show_bug.cgi?id=21245
--- Comment #22 from denis bonnenfant denis.bonnenfant@diderot.org 2010-12-11 11:30:57 CST --- Saving files seems to be significantly faster in 1.3.9. I will experiment a little bit more before closing this bug.
http://bugs.winehq.org/show_bug.cgi?id=21245
denis bonnenfant denis.bonnenfant@diderot.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #23 from denis bonnenfant denis.bonnenfant@diderot.org 2010-12-12 10:39:44 CST --- saving files is now reasonably fast. So this bug can be considered as fixed. Closing it
http://bugs.winehq.org/show_bug.cgi?id=21245
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #24 from Alexandre Julliard julliard@winehq.org 2010-12-24 13:13:49 CST --- Closing bugs fixed in 1.3.10.
-
wine-bugs＠winehq.org