Ultima Posted December 23, 2007 Author Report Share Posted December 23, 2007 I had the filters in the dropdown menu in very early versions, but removed it... just because (I'm not really sure why xD). Ever since I implemented drag-and-drop support, I don't think I've once touched the Open dialog... I guess I'll add it back in (though I'm going to continue defaulting to All files).What kind of test data? A torrent with 3500+ files xD It used to take more than 10 seconds to decode it, but now takes around 1.6 seconds. I'm using an Intel C2D E6600 with 2GB RAM, and don't have access to very old machines to test, but I'm pretty sure it'll be slow. I think I managed to improve bdecoding speed by another 15% since 0.4.1, but remember that 15% isn't much anymore, considering the fact that it's sub-2seconds that I'm comparing now. I don't have old machines in mind so much as I do have just general optimization in mind. Link to comment Share on other sites More sharing options...
noname12 Posted December 28, 2007 Report Share Posted December 28, 2007 This tool is very good!Thanks Link to comment Share on other sites More sharing options...
jewelisheaven Posted December 28, 2007 Report Share Posted December 28, 2007 Blah! Now you have me wanting to make "impossible" files to see how it compares on my system. I thought 1200 files or 200 keys was "alot" since you rarely see that many in legitimate torrents. Read as: GOOD PROGRAM, and I want to break it Edit: here's a screencap of the resume.dat for 1.8 and only 635 torrents loaded :/ Is that expected since each torrent now has ~50 subkeys? Comparatively the 2nd picture is 4201 torrents in the 1.7 stable. The 3rd is process explorer showing vital stats for the editor during opening/decoding. ... 778 vs 620 entries decoded per second according to ROOT keys * entries / TreeViewFill timeAlso during decoding process the editor only functions near max CPU usage in 9-15 second increments... is this the actual decoding of each root key? Link to comment Share on other sites More sharing options...
Ultima Posted December 31, 2007 Author Report Share Posted December 31, 2007 That's rather slow I'm running out of ways to optimize the decoding algorithm and treeview filling process -- it's probably at (or rather close to) the limits of what the scripting language I'm using can do.I'm not sure what's up with the "segments" in decoding -- my CPU usage graph plateaus until it finishes decoding so that in the end, I see a trapezoid of some sort. Link to comment Share on other sites More sharing options...
jewelisheaven Posted December 31, 2007 Report Share Posted December 31, 2007 Well the only reason i asked was because it didn't align completely, or totally with MY CPU usage. The sample 1.7 resume.dat completely freezes my CPU (80% usage spike) for 1-1.5 seconds every save of it due to the hashing.As far as the speed... that's the same as your sample decode, 620 keys per second for 2 seconds is ~ your sample number. (4201*36=151236/243.705=620.5 AND 635*50=31750/40.809=778)I gave reference values and primary keys off the root as well as subkeys for verification. In any case, this will have saved me HOURS when I am finally able to have time to futz with migrating this to 1.8 -> (relative paths ftl ugh).Edit: I forgot HAPPY NEW YEAR! :cheer: ozzies kiwis and others on the pacific rim Link to comment Share on other sites More sharing options...
GTHK Posted January 17, 2008 Report Share Posted January 17, 2008 I noticed when you add a list to a list, i.e. putting an item in an "announce-list" list, it comes out as Item -1 when set to bottom instead of top. Thought that might be a bug, also it fixes itself if you click the edit button followed by ok. That little bug aside, great program. Once command line opening came in I set it as a right click option for torrents and associated it with .BEncode files (lets me save Wireshark data as whatever.BEncode and open it in the editor easily). Thanks again. Link to comment Share on other sites More sharing options...
Ultima Posted January 18, 2008 Author Report Share Posted January 18, 2008 Hah, nice catch. I've fixed it in my build, though I can't say for sure when I'll be releasing it. Between finagling with the FAQ/manual and doing a bunch of other stuff (Real Life™ included), I haven't been able to squeeze much time in for BEncode Editor Link to comment Share on other sites More sharing options...
jewelisheaven Posted January 18, 2008 Report Share Posted January 18, 2008 Did you have anything others can help with regarding the manual to ... allow you time for a roll-up release .5? <wink> Link to comment Share on other sites More sharing options...
Ultima Posted January 18, 2008 Author Report Share Posted January 18, 2008 Nah, I'm skipping 1.7.x and jumping straight to 1.8.x for the manual. There haven't been any substantial changes between 1.7.2 and 1.7.6 that would warrant an update to the manual.Edit: lol didn't realize you were referring to BEncode Editor 0.5.0. I thought you were referring to 1.7.5 of the manual... or something O.o I'm out of it To answer your question: not really Link to comment Share on other sites More sharing options...
Ultima Posted January 18, 2008 Author Report Share Posted January 18, 2008 [sNIP] BEncode Editor v0.5 not officially released -- still undergoing some changes. What was previous posted was (as I expected) not up to par with how I would've liked it quality-wise, so it's been pulled. Newer builds are still available further into the thread if you still want to give them a shot.Considering how half of the changelog came between last night and now (quite literally -- all but one feature got added in the last few hours), I feel this build isn't as heavily tested as I would like it to be. As such, consider this a beta/RC (sorta unstable?) build. If no complaints crop up... well, consider it sorta stable then xDHeh, just noticed that someone else stickified the thread Once command line opening came in I set it as a right click option for torrents and associated it with .BEncode filesYep, file association was my main motivation for implementing command line loading in the first place Link to comment Share on other sites More sharing options...
jewelisheaven Posted January 18, 2008 Report Share Posted January 18, 2008 A sticky well deserved... I'm not sure if this is relevant but it appears that .5 resolved the 15 second interval decoding blocks... however I must have missed the memo.. since when did you HAVE to re-pipe output back to the decoded file when click-drag is used? There also seems to be some timing issue related to that 500000 seconds? that's almost a year!As always I have pictures for you... compare to the old numbers.Aside, YES I know scheme is wonky, but I've been using this for 1.8 colouring-testing, and well.. GREEN appears to be a lighter theme while still being NON-white, but still dark enough so as to not cause eye strain Edit: 1.2 - 1.8 ratios were obtained (old decode times / new decode times) so .. 55-83 % increase in speed?!?!?! Or did I forget something about basic math, lol BRAVO!! Link to comment Share on other sites More sharing options...
Ultima Posted January 18, 2008 Author Report Share Posted January 18, 2008 Hm. Those kind of numbers make me worry about whether my decoding algo got b0rked somewhere along the way O.oCan you post a copy of your resume.dat for me to mess around with? I'll edit the link out for you as soon as I grab it.since when did you HAVE to re-pipe output back to the decoded file when click-drag is used?What do you mean? Link to comment Share on other sites More sharing options...
jewelisheaven Posted January 18, 2008 Report Share Posted January 18, 2008 Drat I don't seem to have an email for you. Sure I'll upload it. I told you though it's just decoding what I sent it. [sNIP] is the dat file. For the pictures, the double encode/decode and display blocks were ONLY experienced when I click-dragged the file into the BFE window. Note the log (could you make a menu option or context menu for "copy log" so pictures aren't necessary?) only shows the 500K+ for those operations. File->Open operations only show one decode and treeview display process. Did you want my other file... with the 50 subkeys per file for 1.8?Edit: For clarity, BFE is re-saving the files you click-drag into the window. (thereby resetting the last modified time of this resume.dat for ex, which hasn't been touched since my last picture of it). Link to comment Share on other sites More sharing options...
Ultima Posted January 18, 2008 Author Report Share Posted January 18, 2008 lmao 4MB dat file... xDI'll take a look at the stuff you've mentioned. Thanks Edit: I can't seem to reproduce the problems you're experiencing... Link to comment Share on other sites More sharing options...
jewelisheaven Posted January 18, 2008 Report Share Posted January 18, 2008 i TOLD you... 4201 loaded torrents, oi! You'd think after all the constructive criticism I've contributed you'd take my word for it without seeing for yourself As I said the double blocks and HUEG numbers only exist for click-drag loaded files. OH! i'm running Unicode btw. Link to comment Share on other sites More sharing options...
Ultima Posted January 19, 2008 Author Report Share Posted January 19, 2008 Question: did you (or something on your computer) happen to be pressing Ctrl+S or Ctrl+R while it was decoding? If so, then that's the source of your problem. The reason lies behind how I'm hooking the hotkeys. In reality, I'm not using normal per-application hotkeys (via accelerator tables). What I'm using are global hotkeys that act like normal hotkeys by detecting window focus. The only problem is, when the application is busy (decoding), it won't properly unregister the global hotkeys, and it'll keep acting on them. Net result? Possibly what you see.I might be able to get it to use accelerator tables, but that'll have to wait a few days -- I'm going to be busy tomorrow Link to comment Share on other sites More sharing options...
jewelisheaven Posted January 19, 2008 Report Share Posted January 19, 2008 So the entire time of decoding global hotkeys Ctrl-R and Ctrl-S are recognized (I presume also the rest of them, ^F ^H Ins Del Alt-Enter)... sure I'm always awake spidering the forums No need for a new update as long as I know what NOT to do..... Do my numbers stand up.. With the same testfile are you experiencing ~50% decreased decoding time vs. .41?Edit: Are you sure it's not just Ctrl being recognized as down... I do frequently Ctrl-Tab Ctrl-Shift-Tab because in my general firefox session I have ~ 40 tabs... Link to comment Share on other sites More sharing options...
Ultima Posted January 19, 2008 Author Report Share Posted January 19, 2008 I still have only 15% improvement (though that equates to 2.8 seconds of improvment in decoding your massive resume.dat -- 18.8 vs 16). It might be because of my computer specs? I'm not really sure. Either way, the decoding seems fine, so I the performance boost looks legitimate to me if those are really the numbers you got.It's definitely not the Ctrl key, because Ctrl does absolutely nothing in BEncode Editor Have you tried the raw inputs and file importing? How about exporting? I feel like they need more testing Edit: BTW, your .dat file still amazes me as to how many keys and subkeys there are. It's so much that after expanding all keys, Windows runs into some kind of treeview limitation whereby it won't allow you to scroll any further down even though there are clearly more items below what appears to be the last item (when you press End on the keyboard). Heh.Edit: Which reminds me... One thing I'm feeling the need to note is the fact that adding the "double-click edits the item" feature causes the treeview expansion (pressing * on your numpad on the ROOT item) to slow down VERY dramatically. Nothing I can really do about that unless I remove the double-click support, unfortunately. *shrug* Link to comment Share on other sites More sharing options...
jewelisheaven Posted January 19, 2008 Report Share Posted January 19, 2008 I see Item -> Export (is that the undocumented ^R?) where is raw input? Give me your email!!! Link to comment Share on other sites More sharing options...
Ultima Posted January 19, 2008 Author Report Share Posted January 19, 2008 Ctrl+R is a keyboard shortcut for reloading the treeview (that reload button). Yeah, it's not documented Raw input is in the Add and Edit dialogs (you'll find it in the Type dropdown).Email? What for? I don't really have a public-ish one at the moment -- only ones I use to sign up for random sites to avoid spam in my personal inbox ;D Link to comment Share on other sites More sharing options...
bonaventura Posted January 19, 2008 Report Share Posted January 19, 2008 Hi Ultima, I just wanted to drop a note in here saying "Thank you very much" for your editor. It turned out to be a handy tool in solving all the problems with my corrupted .dat files which I describe in this thread.FYI: I used BEE 0.4.1.0 (unicode) on a win2k SP2 machine, and it worked flawlessly.So kudos once again and keep up your good work Link to comment Share on other sites More sharing options...
Ultima Posted January 20, 2008 Author Report Share Posted January 20, 2008 I'm glad it's been of use to you Another v0.5 build! Unicode and ANSI. It would be nice if someone on pre-XP would test this build to make sure hotkeys still work on those OSes.Changelogv0.5.0 (2008-01-20) + Feature: "Item" menu with associated keyboard shortcuts + Feature: Copy Logger tab items with Ctrl+C + Feature: Double-click to edit item + Feature: Export data from selected item + Feature: Import external file as binary data + Feature: Input raw BEncoded data directly or from an external file ~ Change: Add .torrent and .dat to dropdown list in Open/Save dialogs ~ Change: Faster bdecoding (~15% improvement over v0.4.1 in tests) ~ Change: Miscellaneous polish to Find/Replace ~ Change: Use accelerator table instead of global hotkeys * Fix: "ITEM -1" when adding child list/dictionary to bottom of list * Fix: "Reached beginning/end of document" message sometimes shown twice * Fix: Combobox not showing options in dropdown on pre-XP systems * Fix: Strings can replace integers in Find/Replace * Fix: Typo in Logger entry for BEncoding * Fix: Using "Find Next" sometimes returns focus to wrong windowAs you might've noticed, I haven't yet updated the first post -- that's because I'm letting you guinea pig for me before I make it official 0.5 Just a quick note... Using accelerator tables has made the hotkeys (sometimes) less responsive (meaning that they don't always work every single time -- it may take several presses). There isn't much I can do about it, but at the least, it's preferable over the ugly "hack" that global hotkeys was (I've been meaning to get rid of it for a while anyhow). Feedback please! @jewelisheaven: F5 was actually another alias for refreshing (it did the same thing as Ctrl+R too). In the end, I decided to remove both hotkeys entirely because the feature itself (reloading) is almost never needed. I myself have only used it to debug some features to make sure items/text are added/modified properly. All it does is reload the treeview -- it doesn't even reload the file from disk. I'd say it must've been dumb luck that you never ran into the global hotkeys' drawbacks before Link to comment Share on other sites More sharing options...
Firon Posted January 20, 2008 Report Share Posted January 20, 2008 9x can go to hell Link to comment Share on other sites More sharing options...
jewelisheaven Posted January 20, 2008 Report Share Posted January 20, 2008 I tested the new Item menu. Link to comment Share on other sites More sharing options...
Ultima Posted January 20, 2008 Author Report Share Posted January 20, 2008 The "Item" menu isn't actually all that interesting... Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.