|
OK, color me blind and not-too-bright. Just below the top menu bar there is the "standard" toolbar that specifies debug/release and processor. Changing the settings there has affected the file size and the directory it is written to. I'll see if it makes a difference in whether it works on a machine that does not have the SDK installed.
|
|
|
|
|
Nope, that didn't do it. I downloaded a utility called Exception Hunter and it tells me that DirectX.DirectSound is not installed on the problem computer. I think the best approach is to assume that's correct and put in some code to find out whether it's installed on the user's machine.
I assume that's in the Registry someplace? Does anybody happen to know?
|
|
|
|
|
tjeffries wrote: it tells me that DirectX.DirectSound is not installed
Hmmm, it should be installed as a normal part of the redist or SDK, so I'm not sure why it wouldn't be there.
A quick check on my machine shows it lives in "C:\Windows\Microsoft.NET\DirectX for Managed Code", although this is on Vista, so it might be slightly different if you're on XP. (My home machine is XP, but I'm at work just now.)
As a last resort you could always search under C:\Windows for all DLLs, and see if you can identify any DirectX ones - a bit of a slog, but I can't think of any other way at the moment.
The other thing to check is if it's in the GAC (C:\Windows\Assembly) although I've never found a way to back track from a GAC reference to the actual DLL location. There again, if it's in the GAC, it must be on the machine somewhere, I think.
I'll add an update later if I think of anything else...
There are three kinds of people in the world - those who can count and those who can't...
|
|
|
|
|
Thanks, that's very helpful. I was trying to figure out why a machine that could play other audio apps couldn't play this one, but the fact that it has to use a special "managed" version explains the problem.
Your help has been very much appreciated!
Warning- sarcasm ahead:
I can't possibly express how much I appreciate the way Microsoft has helped me avoid actually writing code for the last few days while I figured out how to work with their protection mechanisms. I can't imagine how I was ever able to write solid drivers that never broke in assembler and C.
/sarcasm
|
|
|
|
|
Hi
i'm looking for a way to improve .net app performance, i've used ngen.exe to perform this, but i didn't get good result.
can anybody help me about this issue ?
thanks
|
|
|
|
|
yes, assuming you provide full description and some code.
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
|
|
|
|
|
Hi Luc
i mean improvement startup time of .net app. can u help me (any way or tips to do this by ngen or other tools)?
|
|
|
|
|
There is no magic solution to performance problems.
Tools may help you in figuring out where the problem is, common sense should do that too (unless there are many people, and many component vendors involved).
Some tools may claim and try and improve performance a bit, IMO all too often what they do is try and remedy something that is basically wrong, and should be fixed, not softened up a bit.
Startup time is determined by:
1. the amount of code that needs to be loaded, rebased and organized; having lots of DLL files on distant servers would not help. Dynamically loading things, if and when required, could be a step in the right direction.
2. the amount of user code that needs to be jitted; occasionally splitting some huge classes in smaller ones might help.
3. the amount of user code that needs to be executed before the app becomes useful; not showing anything until a complex form full of database information is shown, would be wrong. A splash screen does not help objectively, it eases the user's mind though. Postponing operations whose results are not needed from the very first moment is always a good idea.
Furthermore, startup latency may be improved by all the measures that improve performance in general: not executing what is not needed, choosing appropriate algorithms, not making things unnecessarily complex, avoiding Forms with 50+ Controls, using efficient coding techniques, being economical with objects (e.g. not creating a new Font for every word on a Form).
And if CPU load is way below 100% during critical periods, using asynchronous operations and/or multi-threading judiciously will be a big help.
I always include logging code in my apps; my log shows major actions with current time, and outputs that to a text file; anytime two consecutive logs are more than 100 msec apart, I get suspicious and try and figure out why the app isn't moving forward.
In all, getting the right performance is part of software development, there is some science to it, and some art; it takes lots of common sense and experience, and no magic.
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
|
|
|
|
|
Depends - do you mean the startup time for .NET ( nothing you can do, really ), or your app ( it's kind of insane to ask that without showing us code )
Christian Graus
Driven to the arms of OSX by Vista.
"! i don't exactly like or do programming and it only gives me a headache." - spotted in VB forums.
I can do things with my brain that I can't even google. I can flex the front part of my brain instantly anytime I want. It can be exhausting and it even causes me vision problems for some reason. - CaptainSeeSharp
|
|
|
|
|
Thanks Christian
i mean startup time for .net apps (generally)
|
|
|
|
|
Adding to what others said, you can try using RuntimeHelpers.PrepareMethod to pre-JIT. This improves the load time. When a .NET application starts, you can always expect a small delay as CLR loads. In C++, you can use /DelayLoad:dllname[^] linker option to delay loading of a DLL. So it will be loaded the first time when it is used and this can improve the startup time. I am not sure the equivalent of this in C#.
|
|
|
|
|
1. Where would the call to PrepareMethod be? If it's in startup, it would slow things down even more.
2. MSDN[^] says that PrepareMethod "Prepares a method for inclusion in a Constrained Execution Region (CER) with the specified instantiation.". Nowhere does it mention that the method is JITted. AFAIK, CERs are created to make sure that certain code gets executed always in the face of errors, however critical they may be.
N a v a n e e t h wrote: In C++, you can use /DelayLoad:dllname[^] linker option to delay loading of a DLL.
That is how .NET works by default - assemblies are loaded only when a method referencing a type in an assembly is JITted does an assembly get loaded.
|
|
|
|
|
S. Senthil Kumar wrote: it would slow things down even more.
But I have an opposite experience. I can see slight changes when I used this.
2 - Yes, MSDN is not saying that methods are jitted. I got the idea from JIT methods at runtime[^] article. It worked well in my case.
S. Senthil Kumar wrote: assemblies are loaded only when a method referencing a type in an assembly is JITted does an assembly get loaded.
Yes. But the delay you are seeing is CLR loads not the assemblies you have used loading. We can even delay the loading of these assemblies. Read this[^].
|
|
|
|
|
N a v a n e e t h wrote:
But I have an opposite experience. I can see slight changes when I used this
I'm not convinced. I read the article you linked to and the author's response to your comment - he says he'll hide the initial delay by showing a splash screen. The author's idea is to take the JITting performance hit upfront rather than amortizing it over the running time of the application - there's still a performance hit. I haven't seen it in practice though.
N a v a n e e t h wrote: Yes. But the delay you are seeing is CLR loads not the assemblies you have used loading. We can even delay the loading of these assemblies. Read this[^].
Again, the article says this is useful if the startup code isn't doing pure unmanaged stuff. Only C++/CLI offers that ability, code compiled in all other languages will immediately require the CLR's services anway.
Interesting links though, thanks.
|
|
|
|
|
How fast is fast? You have to provide some metrics about what you have and what you're looking for.
only two letters away from being an asset
|
|
|
|
|
If I were you, I'd profile the application looking to see where the "slowdowns" actually are. You can ngen all you like, but if you're performing unnecessary work, this isn't going to help you in any way.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Hi,
I need to create a small program that removes duplicates of same picture, but by duplicate I mean that one picture can be a wallpaper and the other one a very small picture, both being "identical". Any ideas?
Thanks
modified on Monday, June 15, 2009 5:05 PM
|
|
|
|
|
Do you mean (Same Image AND Different Size) ? are Identical ?
I know nothing , I know nothing ...
|
|
|
|
|
Yes, same image in different sizes
|
|
|
|
|
identical as in tiger == cat ?
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
|
|
|
|
|
Not sure what you mean by that. I mean that for example, you have an wallpaper size image whih was shrinked using some tool. Is it possible to compare them?
|
|
|
|
|
You will have to decide for yourself when you call two images identical.
Here is one possibility:
- shrink the larger one to the size of the smaller one;
- now you have to images of identical size; iterate over all pixels in both, calculate the pixel difference, and make a histogram of that deviation.
Pixel difference could be (red1-red2)^2 + (blue1-blue2)^2 + (green1-green2)^2 or something similar.
Then apply some criterium on the histogram to judge equality.
Drawbacks:
1. this will not be fast;
2. the shrink you apply may be somewhat different from the original shrink;
3. the algorithm will fail if one picture is a shrink of only a (large) part of the other
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
|
|
|
|
|
I always found my self , at the voting button every time I read an answer for you ...
please kindly accept respect.
Kind regards .... ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
I know nothing , I know nothing ...
|
|
|
|
|
Thanks for the kind words, not sure how they fit together with a 1-vote though.
[EDIT]That's better![/EDIT]
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
modified on Monday, June 15, 2009 6:11 PM
|
|
|
|
|
I thought Vote 1 = is Number 1 = 1st = The Top 
any way I fixed that 
I know nothing , I know nothing ...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
