Intro Download and install Frequently Asked Questions Tips and tricks

Homepage







© J.C. Kessels 2009
MyDefrag Forum
December 20, 2014, 03:57:09 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: 1 [2]
  Print  
Author Topic: [Tool] MyDefrag Script Creator *Alpha version*  (Read 8562 times)
Darlis
JkDefrag Hero
*****
Posts: 1785


View Profile WWW
« Reply #15 on: July 18, 2010, 09:00:56 am »

Choosing the language only by performance is a poor choice.
In my case, performance is not relevant. I need a good object oriented language, like Java. The only significant performance difference is in the startup of the JVM.
Logged

Need help creating a script? Try MyDefrag Script Creator.
Kasuha
JkDefrag Hero
*****
Posts: 595


View Profile
« Reply #16 on: July 18, 2010, 09:26:28 am »

Oh that's good news...

Somehow ... I don'T like Java much...
Dont' ask me why. If I think of the performance,
it is way slower than native programs but some
experts say that Java is not much slower than
C / C++ but shurely it does not have the speed
when you use ASM.

Some of you might think similar about .NET.
But .NET recompiles the intermediate code while
running and it will get even more speed than
ASM (sometimes on some plattforms).

.NET is about as good as Java was five years ago. Java also compiles its code (ever heard about JIT?) but that still makes its code about as fast as C/C++ with no optimizations. And no, .NET is not better.
If you look at the thing from raw performance point of view, both .NET and Java are inferior. But they (and especially Java) have two big advantages:
1/ portability. The ability to run exactly the same code on wide variety of machines often more than ballances the lack of performance.
2/ applications often don't have to be faster than user input driving them

If MyDefrag was written in Java you'd probably not notice any significant speed difference, as most of the time it's in native procedures (MS defrag API) anyway.

I also disliked Java (for its performance) long time ago. But I learned it has its place on the market.
Logged
BloodySword
Global Moderator
JkDefrag Hero
*****
Posts: 1158



View Profile
« Reply #17 on: July 18, 2010, 11:11:57 am »

Yes if you build a script generator, speed is not important.

But I have built an ADPCM encoder in .NET wich compresses the frames with ZLIB (even written in purely .NET). It is VERY(!!!) fast. Such operations should not be as fast as user input. It would take millieniums ;o). It compresses 4 Minutes CDDA audio (44100 Hz, 16 Bit, Stereo) on my Core 2 Duo @ 2GHz in about 12 seconds. And it uses ALL ZLIB levels and takes the smallest result for every (1 second long by default) frame. The sound is good for most music but some sounds very crispy noised (because of the 4 bit ADPCM bit reduction).

It is interesting how many languages are out there now. You could do this things I did even in PHP. O_O
Logged

Greetings from Germany!
stormin norman
JkDefrag Junior
**
Posts: 6


View Profile
« Reply #18 on: July 26, 2010, 08:40:40 am »

I can by going to the Prefetch folder, getting administrator rights (UAC), opening the layout.ini with Notepad++, edit and save. I use Win7 with active UAC. I know that not all files in the system and program folder are editable like that, because of the permissions.
Alas this is not possible in XP to my knowledge, even with an admin account.

MyDefrag offers a few commands to sort files (name, size, dates, etc.). Apart from that, the layout.ini is sorted in a special way: In the order the files are loaded. Any other sorting would make the system slower.
To be able to look at the file is a good idea and easy to implement, but altering the content may not, especially for the layout.ini which always changes. You'll have to edit the file every time. Instead of removing files from the list, you could use "not()" to exclude these file every time. Could you give me a specific example how you want to edit the file? And what is the second column intended for?
I'm suggesting two columns so it would be temporarily sorted for the user. The extra column to preserve the order of files as they need to be loaded. The sorting would only be cosmetic, to allow the user locate and remove rogue entries (ie we sort the layout.ini alphabetically, or show entries with the letters ZIP). Which leads me to why one might want to edit the file. I've noticed from observation that windows (XP at least) often includes files in the layout.ini that are not used, or should not be moved to the front of the disk.
As we all know, the layout.ini changes often. But it is suffice to say that the difference those little changes may make is minimal (ie if we haven't install new software or changed our usage patterns). Hence the idea of essentially cloning the layout.ini, and pointing to the clone in the script generator.

Yes if you build a script generator, speed is not important.

But I have built an ADPCM encoder in .NET wich compresses the frames with ZLIB (even written in purely .NET). It is VERY(!!!) fast.
Given that my experience with HPC was computer simulation modelling, where a 20% increase in speed might mean your simulation taking 6 days to complete instead of 7 - everyone was using fortran 77. 10,000 lines of manually optimised procedural code. To be run on a high performance unix system, which you could only access via ssh. .NET or ASM just wouldn't cut it. Incidentally there is no user input, so you wanted it as fast as possible mathematics wise - even if it was a nightmare to maintain.

I support Darlis' choice of Java, because it is by far easier to develop stuff in. It is fast enough for this kind of stuff. Plenty of wonderful java apps out there, I used azureus(vuze) fine for years.



Logged
Darlis
JkDefrag Hero
*****
Posts: 1785


View Profile WWW
« Reply #19 on: July 26, 2010, 12:20:10 pm »

I've noticed from observation that windows (XP at least) often includes files in the layout.ini that are not used, or should not be moved to the front of the disk.
As we all know, the layout.ini changes often. But it is suffice to say that the difference those little changes may make is minimal (ie if we haven't install new software or changed our usage patterns). Hence the idea of essentially cloning the layout.ini, and pointing to the clone in the script generator.
Sorry, but I have to disagree on this. Every time the layout.ini changes, you would have to do these changes again or use the old cloned layout.ini. When setting the file group with the layout.ini, you' get the chance to exclude files (like all .zip files). These files will then always be excluded, hence no altering is needed.

Plus, there are also the .pf files which are unfortunately not just a plain list of files. Editing those would be more work.
Logged

Need help creating a script? Try MyDefrag Script Creator.
Darlis
JkDefrag Hero
*****
Posts: 1785


View Profile WWW
« Reply #20 on: August 17, 2010, 04:34:54 pm »

Alpha 2 is done!
See the first post for the tool and the changes made.
Logged

Need help creating a script? Try MyDefrag Script Creator.
stormin norman
JkDefrag Junior
**
Posts: 6


View Profile
« Reply #21 on: August 18, 2010, 04:53:17 am »

Sorry, but I have to disagree on this. Every time the layout.ini changes, you would have to do these changes again or use the old cloned layout.ini.
The latter is precisely what I'm suggesting. As I was saying, I don't see much of a impact using an optimised copy of the layout.ini over a month old - unless our usage pattern just changed significantly (new software installed) or critical updates in windows. Once one had a good script, you'd only need to 'refresh' & trim the layout.ini as required.

When setting the file group with the layout.ini, you' get the chance to exclude files (like all .zip files). These files will then always be excluded, hence no altering is needed.
I'm aware of this, and it does help (cached swf files are another example of crap in the layout.ini - i don't understand why they'd prefetch temporary browser files). But considering my current layout.ini has "C:\PROGRAM FILES\NEVERWINTERNIGHTS\NWN\NWN.EXE" which I haven't run in over a year, and mostly certainly not the last time I rebuilt the prefetch folder, it becomes an issue. I believe this is because windows tries to prefetch exe's linked in the startmenu. All of this stuff doesn't need to be at the front of the disk. Alot of it would be better off grouped in the folder its located.

Plus, there are also the .pf files which are unfortunately not just a plain list of files. Editing those would be more work.
Can't we just leave those as is? Wouldn't removing entries from the layout.ini be enough?

I supposed the bottom line is as such - for the time and effort of programming the feature - is it really worth it. Are we likely to a performance increase tidying up our layout.ini?
Logged
Darlis
JkDefrag Hero
*****
Posts: 1785


View Profile WWW
« Reply #22 on: August 18, 2010, 09:40:56 am »

Sorry, but I have to disagree on this. Every time the layout.ini changes, you would have to do these changes again or use the old cloned layout.ini.
The latter is precisely what I'm suggesting. As I was saying, I don't see much of a impact using an optimised copy of the layout.ini over a month old - unless our usage pattern just changed significantly (new software installed) or critical updates in windows. Once one had a good script, you'd only need to 'refresh' & trim the layout.ini as required.
Copying the layout.ini and using this copy for a certain time can make the boot zone more stable. I could do that, but I have to put some kind of expiry date on it, otherwise you would use the old file all the time. But still, no editing of the file itself. Wink

Plus, there are also the .pf files which are unfortunately not just a plain list of files. Editing those would be more work.
Can't we just leave those as is? Wouldn't removing entries from the layout.ini be enough?
Of course I will leave them. Plus you're not forced to exclude files from them at any point. But if I'm going to copy the layout.ini for zone stability, I can do so for the prefetch files, too.

I supposed the bottom line is as such - for the time and effort of programming the feature - is it really worth it. Are we likely to a performance increase tidying up our layout.ini?
According to Jeroen, every file that is listed in the layout.ini is accessed i some way. So, if these files are further away from the boot zone, performance will decrease, but I guess it will be only measurable, you won't feel much difference.
Logged

Need help creating a script? Try MyDefrag Script Creator.
Darlis
JkDefrag Hero
*****
Posts: 1785


View Profile WWW
« Reply #23 on: September 29, 2010, 07:00:51 pm »

Small update: I'm now halfway through the first Beta. The volume & file selection views, plus the file groups managing are done. You can see them in action in the exclusions section on the attached picture.


* MyDeSC early Beta screenshot.jpg (97.51 KB, 1000x909 - viewed 374 times.)
Logged

Need help creating a script? Try MyDefrag Script Creator.
Glowyrm
JkDefrag Junior
**
Posts: 7


View Profile
« Reply #24 on: October 03, 2010, 02:09:10 am »

Hello, I was really intrigued when I saw this post and downloaded your 2nd Alpha release right away.

Thing is, I'm getting a "Java Virtual Machine Error" when I try to run your JAR file.

Quote
Could not find the main class:
C:\<filepath>\MyDeSC.jar. Program will exit.

I have the most recent and correct version of Java for my computer/browser and have verified that it is indeed working correctly and that I am opening the .jar file with the correct Java application (although I have tried all of the ones that were in the Java installation folder since the one that should have worked didn't)

From what I have gathered from some quick research online, the problem seems to be with how the applet was "jarred". I'm guessing that means there's a something in the code or the way it was compiled that doesn't sit well with my system for some reason. I could be wrong, like I said it was just some quick reading up on that error I did.

Has anyone else told you they are receiving this error?

I am using Windows 7 Ultimate 64 bit OS.
Logged
Darlis
JkDefrag Hero
*****
Posts: 1785


View Profile WWW
« Reply #25 on: October 03, 2010, 08:05:38 am »

Has anyone else told you they are receiving this error?
No, you're the first one to tell me. Do you use the 32 bit or the 64 bit version of the JRE?
Logged

Need help creating a script? Try MyDefrag Script Creator.
Darlis
JkDefrag Hero
*****
Posts: 1785


View Profile WWW
« Reply #26 on: October 04, 2010, 03:55:34 pm »

I've tested MyDeSC with both the 32 and 64 bit version of the JRE 6u21 and both run fine. Try checking the integrity of the jar file (MD5: 51DA264EFD4246C2CC0ACF2E70E91E4B) or download it again.
Logged

Need help creating a script? Try MyDefrag Script Creator.
Darlis
JkDefrag Hero
*****
Posts: 1785


View Profile WWW
« Reply #27 on: November 09, 2010, 07:21:53 pm »

My site is now up and running, including forum.  Smiley

http://hofmannc.de/mdsc/index_en.html

There are two new screen shots you can take a look at. The program will still take a bit, though.
Logged

Need help creating a script? Try MyDefrag Script Creator.
Darlis
JkDefrag Hero
*****
Posts: 1785


View Profile WWW
« Reply #28 on: November 16, 2010, 08:03:15 pm »

MyDefrag Script Creator 0.1.0 Beta is (finally) done! Smiley
The tool can be downloaded from here.

[Thread closed]
Logged

Need help creating a script? Try MyDefrag Script Creator.
Pages: 1 [2]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.5 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!