Tuesday, May 11, 2010
New versions of InstEd and InstEd Plus released
They were released on the 27th April actually. A bit slow to update.
Friday, April 30, 2010
Friday, April 16, 2010
Visual Studio 2010
Visual Studio 2010 was released recently. With it comes a new C++ runtime that includes a parallel patterns library, targeted at making it easier to write programs that utilise all the cores in a modern processor.
InstEd does use OMP with some success. The problem with OMP is that it cannot be used with Microsoft's Profile Guided Optimisation. At least not with Visual Studio 2008's linker.
I plan on testing the new parallel patterns library in place of OMP. Unlike OMP, it will tie InstEd to Microsoft's compiler, but I suspect it already is tightly coupled anyway, and I don't see that as a problem for the type of product that it is (distinctly Windows only).
And hopefully, it will provide at least as good performance gains as OMP (perhaps better given its dynamic task allocation), combined with the ability to perform Profile Guided Optimisation for even better performance.
So, the next version of InstEd may be delayed, and may come with the new C++ runtime, depending on when I can get hold of Visual Studio 2010, the time cost in successfully converting the projects, and finally the results of testing.
InstEd does use OMP with some success. The problem with OMP is that it cannot be used with Microsoft's Profile Guided Optimisation. At least not with Visual Studio 2008's linker.
I plan on testing the new parallel patterns library in place of OMP. Unlike OMP, it will tie InstEd to Microsoft's compiler, but I suspect it already is tightly coupled anyway, and I don't see that as a problem for the type of product that it is (distinctly Windows only).
And hopefully, it will provide at least as good performance gains as OMP (perhaps better given its dynamic task allocation), combined with the ability to perform Profile Guided Optimisation for even better performance.
So, the next version of InstEd may be delayed, and may come with the new C++ runtime, depending on when I can get hold of Visual Studio 2010, the time cost in successfully converting the projects, and finally the results of testing.
Thursday, March 18, 2010
New InstEd release coming soon
The last release featured a fairly large re-architecture, which introduced a few annoying bugs.
There was even a comment in the code saying something to the effect "Changed this, hope it doesn't break anything."
Sure enough that change broke something.
The next release fixes those (the ones I know about) and introduces an oft-requested feature: Replace and Replace All.
This will hopefully speed up repackaging even more. (Already I hear independent claims of repackaging work which used to take one and a half hours under Wise can be done in 15 minutes in InstEd/InstEd Plus. I can't verify that, but I am impressed.)
Finally, the Table and Column filters in the Find dialog will actually have some real value. They were added a long time ago with Replace/ReplaceAll in mind, but probably didn't hold much value when doing manual Finds. But being able to filter automatic replacements is quite important.
Working on this feature highlighted a Windows 7 specific bug related to the Table and File column dropdowns in the Find dialog. I noticed on Windows 7 (my development OS now) that the "buttons" to show the dropdown list didn't do anything when clicked. ALT+down still worked, however. When testing the dialog in Visual Studio's dialog editor, the buttons worked as expected. So it was a simple matter of firing up Spy++ and comparing the combobox window styles between InstEd's Find dialog and the equivalent test dialog launched by Visual Studio.
I used to add the WS_HSCROLL window style to the combo boxes which, on older OS's, added a scrollbar to the bottom of the dropdown window, allowing long strings to be viewed completely by scrolling. However it seems that on Windows 7 WS_HSCROLL breaks the combobox "button".
I did some checking and the resource script docs don't list WS_HSCROLL as a valid style for a combobox, so I guess technically I can't expect it to work on new OS's. But, I also know that MS strive for strong backward compatibility, for which they failed here.
Still, I managed to catch it in time for when the comboboxes might be used in anger with the new Replace/ReplaceAll features.
Of course, there are some scenarios where an automatic replace can't take place:
Finally, while you can do ReplaceAll with Row Reference Tracking enabled, you may get constant requests to update referencing rows. For example, when many component names are changed using Find/ReplaceAll, you will likely get a dialog for each component asking to update all referencing rows as well. And depending on your filter, these referencing rows may be automatically updated by the ReplaceAll anyway.
In these situations, it is best to turn off Row Reference Tracking before doing the ReplaceAll.
There was even a comment in the code saying something to the effect "Changed this, hope it doesn't break anything."
Sure enough that change broke something.
The next release fixes those (the ones I know about) and introduces an oft-requested feature: Replace and Replace All.
This will hopefully speed up repackaging even more. (Already I hear independent claims of repackaging work which used to take one and a half hours under Wise can be done in 15 minutes in InstEd/InstEd Plus. I can't verify that, but I am impressed.)
Finally, the Table and Column filters in the Find dialog will actually have some real value. They were added a long time ago with Replace/ReplaceAll in mind, but probably didn't hold much value when doing manual Finds. But being able to filter automatic replacements is quite important.
Working on this feature highlighted a Windows 7 specific bug related to the Table and File column dropdowns in the Find dialog. I noticed on Windows 7 (my development OS now) that the "buttons" to show the dropdown list didn't do anything when clicked. ALT+down still worked, however. When testing the dialog in Visual Studio's dialog editor, the buttons worked as expected. So it was a simple matter of firing up Spy++ and comparing the combobox window styles between InstEd's Find dialog and the equivalent test dialog launched by Visual Studio.
I used to add the WS_HSCROLL window style to the combo boxes which, on older OS's, added a scrollbar to the bottom of the dropdown window, allowing long strings to be viewed completely by scrolling. However it seems that on Windows 7 WS_HSCROLL breaks the combobox "button".
I did some checking and the resource script docs don't list WS_HSCROLL as a valid style for a combobox, so I guess technically I can't expect it to work on new OS's. But, I also know that MS strive for strong backward compatibility, for which they failed here.
Still, I managed to catch it in time for when the comboboxes might be used in anger with the new Replace/ReplaceAll features.
Of course, there are some scenarios where an automatic replace can't take place:
- Replacing a complete string with an empty string (null) on a non-nullable field
- The replacement text would create a duplicate column
- Replacing text in a non-editable table (e.g. _Columns)
Finally, while you can do ReplaceAll with Row Reference Tracking enabled, you may get constant requests to update referencing rows. For example, when many component names are changed using Find/ReplaceAll, you will likely get a dialog for each component asking to update all referencing rows as well. And depending on your filter, these referencing rows may be automatically updated by the ReplaceAll anyway.
In these situations, it is best to turn off Row Reference Tracking before doing the ReplaceAll.
Monday, February 15, 2010
WoW 64
Wow, a 64 bit InstEd. Wouldn't that be great. Well, good at least.
It would be a fairly simple task to compile a 64 bit InstEd.
The sticking point comes with the Windows Installer SDK. Microsoft do not provide 64 bit versions (at least I can't find them) of 2 dll's that InstEd uses, specifically mergemod.dll and evalcom2.dll.
One day I may knock up a 32 bit proxy process for calling these dll's, that a 64 bit InstEd would RPC to. However, hopefully Microsoft will publish 64 bit versions of those dll's soon.
In the meantime, InstEd runs happily on WoW64 and no one has yet complained of running out of address space. So wow, WoW64.
It would be a fairly simple task to compile a 64 bit InstEd.
The sticking point comes with the Windows Installer SDK. Microsoft do not provide 64 bit versions (at least I can't find them) of 2 dll's that InstEd uses, specifically mergemod.dll and evalcom2.dll.
One day I may knock up a 32 bit proxy process for calling these dll's, that a 64 bit InstEd would RPC to. However, hopefully Microsoft will publish 64 bit versions of those dll's soon.
In the meantime, InstEd runs happily on WoW64 and no one has yet complained of running out of address space. So wow, WoW64.
Wednesday, September 2, 2009
Speed Demons
There is a whole genre of utilities written as quickly as possible, to satisfy a short term need, never to see the light of day past next week. But somehow they persist eternally as the worst example of the author's code, simply because they are the only thing that fills that need, and no one has the motivation to re-write them.
I suspect that Orca was probably written as such a utility. Somehow it ended up in the SDK, and now is the tool de rigueur for editing msis when you just want to make a quick change, or find some info quickly.
One unfortunate decision when it was written was to use the listview in non-virtualised mode. A virtualised listview basically means the listview is responsible for layout of the items, but not for managing the memory of the data in the listview. The big advantage is that items don't need to be added to the listview. When items are added to the listview in a non-virtualised mode, they are added one by one, and the strings for each cell are copied (i.e. memory is allocated off the heap, the data is copied, and likely the original string is de-allocated by the listview owner). This happens field by field, with the scrollbar details being updated after each row.
If you open a table in Orca that has thousands of rows, you can often see the thumb tab in the vertical scroll bar visibly shrink as the table is loaded into the listview. This is an indication that the rows are being added one by one.
In a virtualised listview, the rows and fields aren't "added". The listview is simply told: "there are 11654 rows and 9 columns".
At that point the listview adjusts the scrollbar, and calls back to the parent window to get the strings for rendering into the visible cells. The parent doesn't have to copy the strings for the listview to render them, it can simply pass a pointer to it's own copy of the string, saving on heap allocation and de-allocation.
So, why am I blogging about this boring topic? While recently testing some new field editors in InstEd Plus, I pulled out my largest handy msi, and ran some speed tests in Orca and InstEd. Orca loads it very quickly, which is nice. My guess is that is simply enumerates the tables and puts them into the listview on the left.
As you scroll down the tables on the left, the memory usage increases. Presumably Orca is loading the table data from the msi to put into the listview. As I clicked on the File table, there was a 12 second wait for it to load approximately 40000 rows. However the rub comes when clicking on another table and back onto the File table. It's another 12 second wait. So, in my test msi, moving from the File table to the FeatureComponents table and back again is a 17 second round trip. Every time you do it. That can take it's toll on the "quick" editing that you want to do.
In comparison, InstEd completely loads the msi into memory ready for near instantaneous rendering of the tables in less than 3.5 seconds (over a network). It calculates the entire range of relationships in 6 seconds. The soon to be available InstEd Plus field editors can generate a smart editor complete with 80000 file table entries and 22000 registry table entries available for auto-completion in about 1 second.
Don't get me wrong. I understand the choice to use a non-virtualised listview when Orca was written. It was probably never intended to become such a popular tool for editing databases. But it was an unfortunate decision, one that doesn't take much work to fix, and probably needs fixing given Orca's popularity over the years.
Or just use this: InstEd.
I suspect that Orca was probably written as such a utility. Somehow it ended up in the SDK, and now is the tool de rigueur for editing msis when you just want to make a quick change, or find some info quickly.
One unfortunate decision when it was written was to use the listview in non-virtualised mode. A virtualised listview basically means the listview is responsible for layout of the items, but not for managing the memory of the data in the listview. The big advantage is that items don't need to be added to the listview. When items are added to the listview in a non-virtualised mode, they are added one by one, and the strings for each cell are copied (i.e. memory is allocated off the heap, the data is copied, and likely the original string is de-allocated by the listview owner). This happens field by field, with the scrollbar details being updated after each row.
If you open a table in Orca that has thousands of rows, you can often see the thumb tab in the vertical scroll bar visibly shrink as the table is loaded into the listview. This is an indication that the rows are being added one by one.
In a virtualised listview, the rows and fields aren't "added". The listview is simply told: "there are 11654 rows and 9 columns".
At that point the listview adjusts the scrollbar, and calls back to the parent window to get the strings for rendering into the visible cells. The parent doesn't have to copy the strings for the listview to render them, it can simply pass a pointer to it's own copy of the string, saving on heap allocation and de-allocation.
So, why am I blogging about this boring topic? While recently testing some new field editors in InstEd Plus, I pulled out my largest handy msi, and ran some speed tests in Orca and InstEd. Orca loads it very quickly, which is nice. My guess is that is simply enumerates the tables and puts them into the listview on the left.
As you scroll down the tables on the left, the memory usage increases. Presumably Orca is loading the table data from the msi to put into the listview. As I clicked on the File table, there was a 12 second wait for it to load approximately 40000 rows. However the rub comes when clicking on another table and back onto the File table. It's another 12 second wait. So, in my test msi, moving from the File table to the FeatureComponents table and back again is a 17 second round trip. Every time you do it. That can take it's toll on the "quick" editing that you want to do.
In comparison, InstEd completely loads the msi into memory ready for near instantaneous rendering of the tables in less than 3.5 seconds (over a network). It calculates the entire range of relationships in 6 seconds. The soon to be available InstEd Plus field editors can generate a smart editor complete with 80000 file table entries and 22000 registry table entries available for auto-completion in about 1 second.
Don't get me wrong. I understand the choice to use a non-virtualised listview when Orca was written. It was probably never intended to become such a popular tool for editing databases. But it was an unfortunate decision, one that doesn't take much work to fix, and probably needs fixing given Orca's popularity over the years.
Or just use this: InstEd.
Thursday, April 2, 2009
New InstEd Plus video
I have added a new video to the InstEd Plus page showing the source tree management options in the latest version, such as extracting files from the msi or merge module, and adding files to the source tree.
Subscribe to:
Posts (Atom)