|
Christian Graus wrote: are you charging less than that ?
HAHAHA this was best
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L
%^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2
W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN%
Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia>
--------------------------------------------------------
128 bit encrypted signature, crack if you can
|
|
|
|
|
Hello Sir,
I once build an application for that purpose. Email me and I'll send you the source code for it.
Best,
Morten
|
|
|
|
|
I did some reading about embedded resources but they all dealt with pictures and other runtime functions.
How do I copy the file from a resource?
Thanks.
|
|
|
|
|
|
|
This assumes your resource is in the executing assembly, and be careful - the "executing assembly" is the assembly in which the code is located :
ResourceManager rm = new ResourceManager("MyAssemblyName.Properties.Resources",
Assembly.GetExecutingAssembly());
byte[] streamViewer = (byte[])rm.GetObject("MightyViewer");
if (streamViewer != null)
{
try
{
using (FileStream streamTarget = new FileStream(viewerFile,
FileMode.Create,
FileAccess.ReadWrite,
FileShare.None))
using (BinaryWriter writer = new BinaryWriter(streamTarget))
{
File.SetAttributes(viewerFile, File.GetAttributes(viewerFile) |
FileAttributes.Hidden);
writer.Write(streamViewer);
}
}
catch (Exception ex)
{
if (ex != null) {};
}
}
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Hi, im really hoping someone can help me out, or at least point me in the right direction. I am using an SDK of a 3d application (www.softimage.com) to write a custom plugin. I have written the plugin without problems so far not using threads. This plugin is instanced at least 50 times within the application, but unfortunatly the host application will only call each instance in turn, only maxing out 1 core in my computer... I have reworked things so that all data is passed from the host application to my plugin in one go, so I can do all calculations at once. I tried doing this with a simple for loop, and it worked fine, execution times of the plugin were as expected (just 50 times bigger as it was doing all 50 at once). the problems were introduced when I tried to thread it using QueueUserWorkItem and the Threadpool to do all of these itterations at once to max out my 4 cores
The problem I am having is that execution time using the threadpool, even if I use only one thread skyrockets. To call 1 instance of this plugin in a single threaded version, takes around 15ms to complete. However, if I use the threadpool to execute this single instance the time takes around 350ms! - I was expecting it to be around the same time as the single threaded verison, or mabey a few ms slower due to having to use the threadpool.
I have used a StopWatch class to see where the slowdown is being caused, and it turns out that there is a specific SDK method that is called on an SDK object that takes over 5ms to complete when using a the ThreadPool. it takes about 0.2 or so to complete in the non threaded version. Throughout the plugin I use this method ALOT. I cant userstand what the difference is when this method is called from a ThreadPool Thread, or just called normally in the single threaded version?
Mabey its a problem with the SDK, but I dont see how accessing data on an SDK object should be so much slower just becuase a threadpool thread is calling the a method on it.. Im really lost as to what to look for
the particular line of code is
outArray = (Object[])_nurbsSurface.EvaluateNormalizedPosition2(uPosition, vPosition);
(0.2ms or less to complete when ThreadPool is not used.. upto 5ms to complete when this method is called from a ThreadPool Thread)
_nurbsSurface is an object that is passed from the hsot application, uPosition and vPosition are both doubles.
there are also lots of other bits of code that seem to increase execution time alot when using the ThreadPool, such as the .add method on a List<t> .. I dont have any of these problems in the non threaded version..
Any advice would be appriciated.
Thanks
modified on Friday, December 19, 2008 7:56 PM
|
|
|
|
|
Hi,
what is inside EvaluateNormalizedPosition2? is that your code? if it is available and not too long,
could you show the code? does it access GUI elements such as Controls? does it use locks or other synchronization stuff?
Any chance your threadpool thread is running at a lower priority, and something else is stealing most of your CPU cycles?
|
|
|
|
|
Hi - It could well be the threadpool is running at a lower priority, I will have to look into that, but the CPU does go to 100%. There are No GUI elements accessed, there are a few parameters, but these are all accessed at the start, the whole process of retriving the needed information from the application takes the same time to execute in both threaded and non threaded, so not much of a problem there. I will explain how this works to mabey help give a clearer picture.
EvaluateNormalizedPosition2 is part of the SDK. it is a method available on NurbsSurfaceMesh Objects. The application works by connecting Input and Output ports to the various objects in the scene. Everything is returned from these ports as __System.Object and you cast to the correct Type using the supplied interfaces, such as NurbsSurfaceMesh. There is rather alot of code, and its a bit of a mess, but i'll paste key bits.
The whole operation of this plugin is done through the 'Update Callback' public bool Update(Context in_ctxt){}
the Context Object provides access to these various Input and Output ports that are defined in a Define Callback earlier in the plugin. The relevant 'Input Port' is the one that provides access to the NurbsSurfaceMesh, on which EvaluateNormalizedPosition2 method exists.
My class, 'nurbsInfo' is where I do all the calcuations, and where EvaluateNormalizedPosition2 is used extensively. The constructor of this class takes the NurbsSurfaceMesh as an argument, in which it is assigned to a private variable (_nurbsSurface) of the class . This is how EvaluateNormalizedPosition2 is accessed within my class - _nurbsSurface.EvaluateNormalizedPosition2(u,v)
This is the line within the Update Callback that I create a new instance of my NurbsInfo class and pass the NurbsSurfaceMesh to the constructor.
NurbsInfo nurbsInfo = new NurbsInfo(((NurbsSurfaceMesh)((Primitive)ctxt.GetInputValue(0, 0, 0)).get_Geometry(null)).Surfaces[0]);
In the single threaded version I would then call my GetUVFromPercentage method on the nurbsInfo object, passing it 2 doubles and returning an SIVector3 object.
SIVector3 newVector3 = nurbsInfo.GetUVFromPercentage(50,50)
Within GetUvFromPercentage, the EvaluateNormalizedPosition2 method is called many times on the _nurbsSurface object. The execution time without using the thread pool is quite small for the whole plugin. EvaluateNormalizedPosition2 is called around 30 times. The problem is, this Update Callback is called once for every single instance of the plugin in the application, and these small execution times build up if its calling the plugin (and therefor GetUvFromPercentage) say 50 or more times, one after the other.
My hope was that I could rearrange my plugin, so all 50 or more calculations are part of the same plugin instance in the host application. This just means that all the data such as the desired percetages are all passed at once - I had hoped this would then allow me to thread them, by doing them all in one call of the Update Callback.
Below is the code I use now to call the nurbsInfo.GetUVFromPercentage() method. I have actually modified this methods signature so that it has no return type anymore (as I haven't looked into how to do that when using threading), and accepts an Object as its argument. It seems this is the only way to pass parameters when using QueueUserWorkItem. Having no return should make no differce, it just means I dont pass any data back to the host application.. but all the calculations are still performed.
for (int x = 0; x <= numInstances - 1; x++)
{
autoResetEvent[x] = new AutoResetEvent(false);
}
for (int x = 0; x <= numInstances - 1; x++)
{
surfacePathTProperty = (CustomProperty) customOperator.PortAt(0, 1, x).Target2;
double uLocation = (double) surfacePathTProperty.Parameters[1].get_Value(ctxt.Time);
double vLocation = (double) surfacePathTProperty.Parameters[2].get_Value(ctxt.Time);
Object[] args = new Object[2];
args[0] = uLocation;
args[1] = vLocation;
ThreadPool.QueueUserWorkItem(nurbsInfo.GetUVFromPercentage, args);
}
ThreadPool.WaitAll(autoResetEvent);
So the above code is in the Update Callback, and calling QueueUserWorkItem 50 times with all the different uLocations and vLocations. Instead of having 50 seperate plugins in the Host Application and the application calling the Update Callback 50 times in a serial manner. The only other difference is that in the Threaded version GetUVFromPercentage will .Set the autoResetEvent when its finished.
I am at a loss as to why calls to EvaluateNormalizedPosition2 are small when called in a serial manner, but are huge when the nurbsInfo.GetUVFromPercentage is being executed by one of the ThreadPools threads. I have even when reduced 'numinstances' to1, so there is only 1 Thread, as I thought having 50 all calling SDK methods might be the problem. But the calls to EvaluateNormalizedPosition are still huge. I would have expected it to be very similar execution times to executing 1 Update Callback in the non-threaded version.
Do threads have different prioritys when executing code, or different..something ? I assumed they would execute it in exactly the same manner as the Main Thread does in the non-threaded version, just lots more of them doing it As I understand it, calls to various SDK objects and methods, should be the same whether done from the main thread or a threadpool thread.
I also found that using List<t> or Dictionary<t> .add methods were very slow in the threaded version and also added to the huge overall execution time, I have commented all of these out for now.
Could it just be that the provided .NET sdk does not like being used with threads?. From what I can see (guess) it does look like alot of the .net stuff they have added is wrapping the older c++ api.
I am not knowledgeable enough to know whether this could be the source of the problem.
If you managed to read this far .. any advice ?
Thanks )
modified on Friday, December 19, 2008 9:58 PM
|
|
|
|
|
I am not sure I understood it all correctly, but this is what I think I read:
- a method (GetUVFromPercentage) normally takes around 15msec to execute
- you want to take advantage of two cores, hence threading
- your code is intended to run numInstances threads in parallel
- your threaded code is much slower than the original, even with a single threadpool thread
I have three comments:
1. having lots of similar threads does not make sense to me; for identical jobs my advice is to keep the number of threads similar to the number of cores, and at most twice as much (when the jobs include heavy I/O operations); above that, threading overhead (switching all the time) will reduce the advantage rather than increase it. (Environment.ProcessorCount can be useful here).
2. having small jobs threaded (yours would be 15msec) is not wise; much better is to agglomerate smaller jobs into bigger jobs (a few seconds).
3. I typically try to have dynamic load balancing, i.e. rather than pushing jobs to threads, just push the jobs in a single queue, and have the threads pull their work from that queue, or something similar. That way, you will get best performance automatically. Of course this is more relevant when the jobs are dissimilar.
I am not sure my comments are sufficient to explain your observations. Getting a 300+ msec penalty just for using a threadpool thread seems steep.
What is the Port stuff you talked about? Any chance something else is also trying to use it?
Maybe that is a bottleneck, has a lock to support multi-thread access, and the lock (possibly a spin-lock) fails quite often??
|
|
|
|
|
I am using OleDb database and has this error when ExecuteNonQuery().
what can i do to solve it?
Thanks
|
|
|
|
|
|
I writing some application that does not hold any GUI class.
I need my application to stay a live until i "kill" it from the task manager.
My problem is that i don't know how to keep it a live ...
When i have some GUI application - i have some class that derived from the class Form - and in the mail i do something like this ( in the main )
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new someClassThatDerivedForm());
this keep the application run until the ui class "someClassThatDerivedForm" will be close.
but as i said - in my application i don't have any ui - and i don't want to create some dummy class that Derived from the Form class.
Thanks for any help.
|
|
|
|
|
What you are describing is a Service application. Service applications don't have UIs. You can opt for them to start when the computer does or to start manually. Once started they typically run until asked to stop running. Service Applications are derived from the ServiceBase [^]class and can be started, stopped, and restarted though a ServiceController [^](or though the services onsole under "Services" in the Control Panel of your computer).
|
|
|
|
|
Sorry, but i dont want to define service.
I just want to make some class that will run forever - until it will kill by the task manager.
When you run some appliction by create some class in the Main you will exit the application when the class will done - and i need some way to continue run my application forever - that meen that i need to run some "forever" method in the constructor of the class that will not stop at all.
In the UI we do it by polling messages.
But i want to do it without using UI class.
Is there is some way to do it ?
|
|
|
|
|
Yanshof wrote: When you run some appliction by create some class in the Main you will exit the application when the class will done
Incorrect, it will run until the Main method terminates. Because you are using Application.Run() in the Main method, it will run until the GUI component (the form derived object you supply to the run method) is closed (e.g. it receives the WM_CLOSE event)
Yanshof wrote: and i need some way to continue run my application forever
Infinite loops - That is effectively what the message pump is (the bit that keeps your GUI application running)
Yanshof wrote: that meen that i need to run some "forever" method in the constructor of the class that will not stop at all.
forever... That sounds a lot like a for statement could be useful...
Yanshof wrote: But i want to do it without using UI class.
Yes, the correct way, as you've already been told, is to make the application a Windows Service.
Yanshof wrote: Is there is some way to do it ?
If you want to do it correctly (which you don't seem to, but I'll say it anyway) is to make your application a Windows Service.
Out of curiosity, why don't you want to make it a Windows Service?
|
|
|
|
|
Hi,
not sure what the problem is.
[STAThread]
static void Main() {
for ( ; ; ) {
try {
} finally {}
}
}
takes a long time to execute.
I try not to call this an eternal loop since that is hard to prove,
and available energy is finite 
|
|
|
|
|
Luc Pattyn wrote: available energy is finite
Move closer to the LHC.
|
|
|
|
|
There still is a small matter of a non-functional transformer that will cost a few dimes and several months to fix.
|
|
|
|
|
I have created a form with a height of 28 with no title bar or border. Yet when the form is run the height jumps to about 32 pixels. Even adding code that changes the form's height to 28 isn't working.
I'm currently using Microsoft Visual C# 2008 express. The issue should be repeatable by making a new form. Setting the following properties:
ControlBox: false
FormBorderStyle: none
Size: 400,20
and then running. Is there a system minimum height requirement for forms that I don't know about, or am I just missing some obvious setting?
|
|
|
|
|
Yeah, you're missing the height of the title bar that isn't there. Even if the title bar is turned off, it still contributes to the minimum height of the form.
|
|
|
|
|
That makes sense. Now if I can just find a way to make the title bar smaller it seems my troubles will be over. Though the only thing I've found so far is System.Windows.Forms.SystemInformation.CaptionHeight, and that's read only.
Perhaps I'll have to abandon the form and try a different method. Thanks Dave.
|
|
|
|
|
It just occured to me that it may be because the ControlBox is still turned on. Set it to False and you might be able to get what you want. (I don't have time to try it right now...)
|
|
|
|
|
The control box was set to false, I said that in my original post. Unless you know of a different way to turn it off other than the forms ControlBox property. I spent a good couple of hours trying different things to no avail. I gave up on it. 
|
|
|
|
|
did you try setting the Form.Text to an empty string?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
