At the moment I'm programming with Jython on my Laptop, but want to use it on my Raspberry Pi3 (Raspbian) later.
Well the start-up time of my program on my Laptop is under 2s, but on my Pi3 it's up to 30s.
I know the issues are that Jython needs time to start up the JVM and even a Pi3 is not as fast as my 3 year old Laptop, but Is it maybe still possible to reduce this start-up time anyway (without over-clocking my Pi)?
EDIT:
At the end I want to use my .py scripts with the jython-standalone.jar v2.7.0
Well I found a solution which is pretty ok for my Project: For small projects OpenJDK seems to be ok, but some things WON'T work with Jython. I had a sleepless weekend until I get this idea to look which version of Java I was using. With the oracle Java(newest Version) it seems to be as fast as on my Laptop Windows etc. (yes it is a little bit slower, but a second less or more is not necessary in my case).
If there is still a faster way to startup, surprise me. :)
Related
Old hardware in injection molding machines require that I have an old PC only due to scan time issues. Newer technology is of course much faster than the old stuff they used. I'm looking for a work around so this is actually 2 questions in 1.
Is it possible to slow down the "scan time" of my new PC to defeat needing to scour the internet for old PCs?
The software also needs to run in DOS. I dont know a whole lot about VMs but what are your thoughts on using one with DOS installed to run the software?
If I've posted in the wrong section or the wrong site please forgive me.
I have recently started exploring game dev and wanted to do it using the Unreal Engine(4). However, the editor doesn't seem to be loading on my computer. I have displayed the UE4 window I keep having to look at upon launching the engine.
Could anyone please help me with this problem?
Thanks.
I'm no expert in Unreal Engine, and I don't know how long you've waited previously (do tell!), but UE4 is a massive, memory intensive engine that would struggle on any laptop (especially a Macbook). I personally use it on my laptop (an HP Pavillion) so it is possible, but there have been times when I am trying to open a project and I've had to wait for around 30 minutes for the percent to change (it was compiling shaders silently). Although, I've never seen it take too terribly long on startup (not opening a project). Try waiting for 30 minutes and see what happens (if you haven't already), otherwise I'm sure you know Unity is a lighter-weight option with comparable features.
Let me preface this question by saying that I know it takes programs longer to run in valgrind as there is a lot of overhead. This question is not about that.
To ensure that our implementations of data structures have the appropriate runtime, all test cases time out after a certain amount of time (usually around 10 times the amount of time the teacher produced solutions take to run in Valgrind). I ran the test cases on my laptop early in the day and everything was fine. I made two very minor changes later at night (adding one to something and adding a counter for something else, both of which are constant time operations). I reran the tests and I timed out on even the most basic of test cases, like inserting one node. I was freaking out, so I went to the 24/7 computer lab on campus and ran my code on a virtual machine and it worked fine. I ran the binaries on my laptop and they're speedy. I tried turning my computer off and then back on and that didn't fix anything, so I tried updating valgrind but it is up to date. I removed valgrind and then re-installed and that didn't fix the problem either. To verify it is a problem with valgrind and not my code I made a hello_world.cpp then and ran the binary in valgrind with no extra flags. It takes about 15-20 seconds to run. I have absolutely no idea why this is happening. I've not made any changes to my computer. I've skimmed the valgrind documentation, but I cannot pin down what is wrong. I run Fedora 27.
We are running a build of our application using Dojo 1.9 and the build itself is taking an inordinate amount of time to complete. Somewhere along the lines of 10-15 minutes.
Our application is not huge by any means. Maybe 150K LOC. Nothing fancy. Furthermore, when running this build locally using Node, it takes less than a minute.
However, we run the build on a RHEL server with plenty of space and memory, using Rhino. In addition, the tasks are invoked through Ant.
We also use Shrinksafe as the compression mechanism, which could also be the problem. It seems like Shrinksafe is compressing the entire Dojo library (which is enormous) each time the build runs, which seems silly.
Is there anything we can do to speed this up? Or anything we're doing wrong?
Yes, that is inordinate. I have never seen a build take so long, even on an Atom CPU.
In addition to the prior suggestion to use Node.js and not Rhino (by far the biggest killer of build performance), if all of your code has been correctly bundled into layers, you can set optimize to empty string (don’t optimize) and layerOptimize to "closure" (Closure Compiler) in your build profile so only the layers will be run through the optimizer.
Other than that, you should make sure that there isn’t something wrong with the system you are running the build on. (Build files are on NAS with a slow link? Busted CPU fan forcing CPUs to underclock? Ancient CPU with only a single core? Insufficient/bad RAM? Someone else decided to install a TF2 server on it and didn’t tell you?)
I am profiling a C++ application with Intel VTune Amplifier. Most of the time seems to be spent in nvoglv64.dll more precisely in DrvPresentBuffers and/or KeSynchoronizeExecution. Note that I have a NVIDA GeoForce graphic card.
I am new to the application I am profiling and looking for bottleneck and low hanging fruits of optimization. Since most of the time seems to be spent in this NVIDIA dll, I do not know how decode the profiling results.
I would like to know where are those call from my application side in order to build a knowledge of my application. Can someone give me some hint to start :
When exactly do an application call DrvPresentBuffers, what kind of call should I look at (on my application side)
Where can I get more info about how to profile, understand and optimize applications where bottlenecks are in the graphic card dll's.
DrvPresentBuffers is part of the draw code for openGL. That nvoglv64.dll is the 64bit openGL driver for your nVidia card. There is a known performance issue for 64bit Windows 7 and this function on many drivers. I couldn't find a link but you can search the nVidia forum if you are experiencing problems. If there is nothing wrong or nothing going horribly slow then I'm not sure optimization is where I would start when familiarizing myself with a new application.