http://bugs.winehq.org/show_bug.cgi?id=14168
Summary: visual studio 2005 install error Product: Wine Version: 1.0.0 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: fyreme3_rd@yahoo.com
Created an attachment (id=14436) --> (http://bugs.winehq.org/attachment.cgi?id=14436) visual studio 2005 install error
Visual Studio 2005 install error
http://bugs.winehq.org/show_bug.cgi?id=14168
James Hawkins truiken@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #14436|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #1 from James Hawkins truiken@gmail.com 2008-06-28 21:46:00 --- What exactly doesn't work? There's nothing in your log that says the install failed. Screenshots work. fixme's and err's are not bugs.
http://bugs.winehq.org/show_bug.cgi?id=14168
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #2 from norm fyreme3_rd@yahoo.com 2008-07-02 00:34:49 --- (In reply to comment #0)
Created an attachment (id=14436)
--> (http://bugs.winehq.org/attachment.cgi?id=14436) [details]
visual studio 2005 install error
Visual Studio 2005 install error
The install never finished.. it locked up and the last line of the log is where it locked up at.
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #3 from Austin English austinenglish@gmail.com 2008-12-30 18:07:08 --- Is this still an issue in current (1.1.11 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=14168
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #4 from Anastasius Focht focht@gmx.net 2009-01-23 14:45:44 --- Hello,
please close this bug. The reporter didn't bother to consult appdb entry. "Locking up" like behaviour which is the 100% CPU for considerable amount of time (might even exceed 30 mins for slow machines) is a known msi problem.
Regards
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #5 from Anastasius Focht focht@gmx.net 2009-01-23 14:50:19 --- Well, or make it at least "enhancement" and correct the summary accordingly. This is probably very low priority for James, it's still on his TODO list.
Regards
http://bugs.winehq.org/show_bug.cgi?id=14168
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords| |Installer
--- Comment #6 from Austin English austinenglish@gmail.com 2009-01-23 16:03:52 --- Confirming.
http://bugs.winehq.org/show_bug.cgi?id=14168
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|visual studio 2005 install |visual studio 2005 installer |error |appears to lock up because | |of poor performance
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #7 from Austin English austinenglish@gmail.com 2009-07-30 12:09:10 --- Is this still an issue in current (1.1.26 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=14168
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #8 from Dan Kegel dank@kegel.com 2009-11-29 12:13:04 --- Still happening. During "setup is loading installation components" phase,
oprofile's opreport shows:
samples| %| ------------------ 79305 75.2676 libwine.so.1.0 7907 7.5045 no-vmlinux 7310 6.9379 kernel32.dll.so 4410 4.1855 msi.dll.so
and opreport -l libwine.so shows
samples % symbol name 3037543 87.7905 strlenW 238941 6.9058 compare_unicode_weights 69079 1.9965 wine_compare_string 59294 1.7137 real_length
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #9 from Dan Kegel dank@kegel.com 2009-11-29 12:55:10 --- Also: opreport -l wine-git/dlls/kernel32/kernel32.dll.so samples % symbol name 1915748 49.8721 CompareStringW 773772 20.1434 lstrcmpW 336447 8.7586 GetThreadLocale 269485 7.0154 __i686.get_pc_thunk.bx
opreport -l wine-git/dlls/msi/msi.dll.so samples % symbol name 1842988 76.4079 msi_string2idW 131731 5.4614 lstrcmpW 106685 4.4230 msistring_makehash 88154 3.6548 __wine_spec_get_pc_thunk_eax
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #10 from Hans Leidekker hans@meelstraat.net 2009-11-30 04:59:01 --- Created an attachment (id=25023) --> (http://bugs.winehq.org/attachment.cgi?id=25023) msi: Store string length.
Does this patch help?
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #11 from Dmitry Timoshkov dmitry@codeweavers.com 2009-11-30 05:30:45 --- (In reply to comment #10)
Created an attachment (id=25023)
--> (http://bugs.winehq.org/attachment.cgi?id=25023) [details]
msi: Store string length. Does this patch help?
if ((str == se[n].str) || !lstrcmpW(str, se[n].str))
if ((str == se[n].str) || (len == se[n].len && !lstrcmpW(str, se[n].str)))
Is it possible to use memcmp() instead of lstrcmpW() here?
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #12 from Dan Kegel dank@kegel.com 2009-11-30 05:53:24 --- It does seem to help noticably, I think it's worth it.
And after applying it, the bottleneck does shift as expected: # opreport 23478 43.6662 msi.dll.so 15057 28.0042 libwine.so.1.0
# opreport -l ~dank/wine-git/dlls/msi/msi.dll.so 200170 87.7054 msi_string2idW 9590 4.2019 msistring_makehash
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #13 from Dan Kegel dank@kegel.com 2009-11-30 06:25:33 --- Might want to increase HASH_LEN from 0x101. When I increased it to a prime about 10x larger, the profile was again dominated by strlen, but this time from a different caller:
# opreport | head 286158 83.8602 libwine.so.1.0 23536 6.8974 kernel32.dll.so 19068 5.5880 msi.dll.so 5689 1.6672 no-vmlinux 930 0.2725 ntdll.dll.so
# opreport -l ~dank/wine-git/libs/wine/libwine.so 253335 88.5298 strlenW 20633 7.2104 compare_unicode_weights 5589 1.9531 wine_compare_string
# opreport -l ~dank/wine-git/dlls/msi/msi.dll.so 17015 89.2333 get_loaded_component 849 4.4525 lstrcmpW 568 2.9788 __wine_spec_get_pc_thunk_eax 117 0.6136 find_entry_in_hash 56 0.2937 WHERE_get_dimensions
winedbg bt all says: Backtrace: =>0 0xf7e20e3e strlenW+0x18(str=0x49f4850) 1 0x7ede1659 CompareStringW+0xda 2 0x7ede1bb1 lstrcmpW+0x7a 3 0x7e3c7075 STRCMP_Evaluate+0xc1(wv=0x59aef30, row=6650597, cond=0x59aeef8, val=0x159ce48, record=(nil)) [/home/dank/wine-git/dlls/msi/where.c:309] in msi (0x0159cdc0) 4 0x7e3c734f WHERE_evaluate+0x271(wv=0x59aef30, row=6650597, cond=0x59aeef8, val=0x159ce48, record=(nil)) [/home/dank/wine-git/dlls/msi/where.c:362] in msi (0x0159ce10) 5 0x7e3c7278 WHERE_evaluate+0x19a(wv=0x59aef30, row=6650597, cond=0x59aef18, val=0x159ceb4, record=(nil)) [/home/dank/wine-git/dlls/msi/where.c:348] in msi (0x0159ce60) ...
YMMV.
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #14 from Dan Kegel dank@kegel.com 2009-11-30 06:38:57 --- Later on (again with the patch and the big hash tables), it shifts a bit to join: overall: 159900 47.4177 msi.dll.so 155819 46.2075 libwine.so.1.0 12045 3.5719 kernel32.dll.so 5004 1.4839 no-vmlinux libwine: 129631 83.1933 strlenW 20582 13.2089 compare_unicode_weights 2599 1.6680 wine_compare_string 2306 1.4799 real_length msi: 50151 31.3640 JOIN_fetch_int 26740 16.7230 WHERE_evaluate 23498 14.6954 read_table_int 16140 10.0938 TABLE_fetch_int 9908 6.1964 STRING_evaluate 9245 5.7817 bytes_per_column 6989 4.3709 msi_string_lookup_id
=>0 read_table_int+0x2c(data=0x5994b10, row=0, col=6, bytes=3) [dlls/msi/table.c:951] in msi 1 TABLE_fetch_int+0x258(view=0x5960598, row=0, col=3, val=0x169d0d4) [dlls/msi/table.c:1150] in msi 2 JOIN_fetch_int+0x170(view=0x5960478, row=0, col=3, val=0x169d0d4) [dlls/msi/join.c:84] in msi 3 STRING_evaluate+0x67(wv=0x5960ab8, row=29303732, expr=0x5960870, record=(nil)) [dlls/msi/where.c:275] in msi 4 STRCMP_Evaluate+0x29(wv=0x5960ab8, row=29303732, cond=0x5960918, val=0x169d198, record=(nil)) [dlls/msi/where.c:299] in msi 5 WHERE_evaluate+0x271(wv=0x5960ab8, row=29303732, cond=0x5960918, val=0x169d198, record=(nil)) [dlls/msi/where.c:362] in msi
Somebody could probably spend a merry day chasing a bunch of little optimizations.
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #15 from Dan Kegel dank@kegel.com 2009-11-30 09:10:15 --- With both the above changes, installation took 40 minutes on my Q9300. There was a 26 minute gap between the two directories
c:/windows/winsxs/x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_6e805841 and c:/Program\ Files/CE\ Remote\ Tools
Now I'll try it with the original hash table.
http://bugs.winehq.org/show_bug.cgi?id=14168
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@meelstraat.net
--- Comment #16 from Hans Leidekker hans@meelstraat.net 2009-12-01 04:58:49 --- I gathered some statistics on the number of strings in msi packages.
A small installer of a couple of megabytes in size has several thousands of strings already and installers on the order of tens of megabytes tend to have tens of thousands of strings. This large visual studio installer has over 220000 strings.
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #17 from Alexandre Julliard julliard@winehq.org 2009-12-01 06:29:56 --- I don't think it makes sense to do micro-optimizations to the string comparison. This clearly needs another algorithm to avoid O(n^2) behavior, for instance by sorting the string table beforehand.
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #18 from Henri Verbeet hverbeet@gmail.com 2009-12-01 08:06:43 --- If the main problem is that the string table starts acting like a list due to the fixed bucket count, it might make sense to just replace it with a wine_rb_tree.
http://bugs.winehq.org/show_bug.cgi?id=14168
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|visual studio 2005 |visual studio 2005 |installer appears to lock |installer too slow, msi |up because of poor |O(n^2) behavior? |performance |
--- Comment #19 from Dan Kegel dank@kegel.com 2009-12-01 11:02:06 --- might be worth increasing that hash table size as a quick partial fix, I think it makes the installer more usable
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #20 from Austin English austinenglish@gmail.com 2009-12-01 11:07:41 --- Is this related to bug 12071?
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #21 from Dan Kegel dank@kegel.com 2009-12-01 11:12:06 --- I think so. Not quite a duplicate as there might be other bottlenecks?
http://bugs.winehq.org/show_bug.cgi?id=14168
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |12071
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #22 from Henri Verbeet hverbeet@gmail.com 2009-12-08 07:54:02 --- Created an attachment (id=25118) --> (http://bugs.winehq.org/attachment.cgi?id=25118) wine_rb_tree based stringtable
Mostly out of curiosity, how does the attached patch behave? (I know it has some room for improvement.)
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #23 from Hans Leidekker hans@meelstraat.net 2009-12-09 03:44:06 --- Henri's rbtree implementation brings the time spent in the "loading components" phase down from 50 to 5 minutes on my machine.
I wrote an alternative patch that keeps a sorted array in addition to the hash and uses that for lookups after the buckets are filled up to a certain amount.
This should use less memory than an rbtree, but overall performance is only good if the assumption holds that most strings are added at initialization time, because each addition causes a rebuild of the entire index.
As it turns out this installer shows the worst possible behavior for this algorithm; although the vast majority of strings are added at initialization time (as in every installer), it does a whole bunch of lookups, inserts one string, and repeats.
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #24 from Hans Leidekker hans@meelstraat.net 2009-12-09 03:46:13 --- Created an attachment (id=25135) --> (http://bugs.winehq.org/attachment.cgi?id=25135) msi: Add binary search to string table.
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #25 from Alexandre Julliard julliard@winehq.org 2009-12-09 05:30:07 --- You shouldn't need to rebuild the index every time, once the initial index is sorted you can insert new things at the right place. The only cost is a memmove of the existing index data.
http://bugs.winehq.org/show_bug.cgi?id=14168
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #25135|0 |1 is obsolete| |
--- Comment #26 from Hans Leidekker hans@meelstraat.net 2009-12-10 07:35:15 --- Created an attachment (id=25153) --> (http://bugs.winehq.org/attachment.cgi?id=25153) msi: Add binary search to string table.
This version uses memmove as suggested by Alexandre. It brings the time spent "loading components" down to 4 minutes here.
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #27 from Dan Kegel dank@kegel.com 2009-12-11 23:02:58 --- Still spending lots of time in strcmpW according to oprofile...?
http://bugs.winehq.org/show_bug.cgi?id=14168
--- Comment #28 from Hans Leidekker hans@meelstraat.net 2009-12-12 03:06:04 --- Yes, there may be room for more improvements. For example, the clause that compares strings by address almost never triggers, and I wonder why we aren't using the string table to store more strings, such as table and column names.
http://bugs.winehq.org/show_bug.cgi?id=14168
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |msi
--- Comment #29 from Hans Leidekker hans@meelstraat.net 2009-12-16 15:19:39 --- Commit 2c526b7fe73ebffff7ae13059b6db7a38b7f880f makes lookups a lot faster when the string table holds many strings.
http://bugs.winehq.org/show_bug.cgi?id=14168
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #30 from Dan Kegel dank@kegel.com 2010-01-04 09:45:44 --- Good enough for now. Any further bottlenecks should be reported in another bug.
http://bugs.winehq.org/show_bug.cgi?id=14168
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #31 from Jeff Zaroyko jeffz@jeffz.name 2010-01-09 04:54:48 --- Closing bugs fixed in 1.1.36.
http://bugs.winehq.org/show_bug.cgi?id=14168
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |2c526b7fe73ebffff7ae13059b6 | |db7a38b7f880f
http://bugs.winehq.org/show_bug.cgi?id=14168
Bug 14168 depends on bug 12071, which changed state.
Bug 12071 Summary: MSI SQL joins on tables with many rows are extremely slow ("Nero 7 essentials", "NI Multisim 11.x" installer) http://bugs.winehq.org/show_bug.cgi?id=12071
What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
https://bugs.winehq.org/show_bug.cgi?id=14168
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |https://web.archive.org/web | |/20161115203751/http://down | |load.microsoft.com/download | |/6/f/5/6f5f7a01-50bb-422d-8 | |742-c099c8896969/En_vs_2005 | |_vsts_180_Trial.img
-
wine-bugs＠winehq.org -
WineHQ Bugzilla