Jump to content

jewelisheaven

Established Members
  • Posts

    10,433
  • Joined

  • Last visited

Posts posted by jewelisheaven

  1. aka.. Ctrl-F (just find)

    I only really would like to see an easier "merge" option. My method there is currently scripted, so it's not a BIG deal, it's just tedious.

    That and I can't think of other shortcomings when dealing with (other) bencoded data not already covered here on the forum. Can it be made iterative? Are you still quietly working on a new version? Are you planning on adding any easter eggs :P

  2. o.O but ... >< inDEED. As usual my mouth needs to catch up to the brain :P (I never processed all strings were (B)... it completely skipped my mind, I mean there's text, numbers, and there's list and dictionary containers)

    Well with the ability for now unicode in/out-put I'm guessing you don't treat it as a special case then? Let it marinate... and stew, and brew.

  3. Binary data would presumably be excluded from a regex? I don't know about a replace *, your idea of the extra box with "key and value" worked after the ideas were proffered. I'm sure after some marination you'll think of something :D

  4. I don't know for sure.. but could you copy your %APPDATA%\uTorrent folder and run it with 1.8 self-contained http://utorrent.com/faq.php#How_can_I_share_my_torrents_between_user_profiles.3F with "/RECOVER" appended to the exe to see if it's fixed in 1.8?

    That certainly sounds like a bug... which contrasts with my original understanding of it saving the torrent somewhere it shouldn't, as in the INVOKED user profile instead of the profile of the CURRENT user even though you gave it ELEVATED privileges >< If you really want to get more into it... download Process Monitor from http://sysinternals.com and start logging prior to adding the torrent (Ctrl-E) and log until after you add it and uT is "frozen". Then filter it for the PID of the utorrent.exe process, and look for those "Access Denied" error messages.

  5. I don't think you need to run under a DIFFERENT account. I think you only have to tell Vista THAT you are an administrator... something about "run as elevated user" I think? :/ I've used Vista twice and I didn't get that far in customizing my UI.

  6. k ;) I'm just saying... it IS faster, whether or not it is intentional.

    Do you think .. since you're keeping track how far in the file you are right... when you do [15:54:02] [ERROR] Failed to decode the file "O:\Downloads\111\Num\resume.dat.old.1.bad" it could give some sort of notation (for those who understand it) where it is broken :`(

  7. Well instead of using 80-85% of CPU for BFE when the shell is up, it's 62-67% the other missing 12-15 (up to 28 in the .6 line) is in my shell ONLY when the treeview is filling. Those numbers shaving 25% are with no shell up.

  8. Say what? You want me to walk the process in PE? Or you talking about using reload from file (which doesn't exist in .51) and averaging the numbers again?

    Never mind, I did numbers again anyways... so here's the deal why the numbers are sometimes off by 15-25%, you're doing some overhead in the shell exe(primarily shown in treeview fill) in .6 which is triple which is in .51 (6 vs 18 CPU %)

    [01:37:03] [bDecode] Start: "O:\µTorrent\Old Versions\resume.dat"

    [01:37:37] [bDecode] End (34.969 seconds)

    [01:37:38] [TreeView Fill] Start

    [01:38:22] [TreeView Fill] End (43.387 seconds)

    [01:40:56] [bDecode] Start: "O:\µTorrent\Beta\TAS\resume.dat"

    [01:41:10] [bDecode] End (13.864 seconds)

    [01:41:10] [TreeView Fill] Start

    [01:41:30] [TreeView Fill] End (19.790 seconds)

    [01:41:39] [bDecode] Start: "O:\µTorrent\resume.dat"

    [01:42:48] [bDecode] End (69.228 seconds)

    [01:42:48] [TreeView Fill] Start

    [01:44:01] [TreeView Fill] End (72.111 seconds)

    Here's .6R5 with no shell

    [01:53:57] [bDecode] Start: "O:\µTorrent\Old Versions\resume.dat"

    [01:54:21] [bDecode] End (23.302 seconds)

    [01:54:21] [TreeView Fill] Start

    [01:54:42] [TreeView Fill] End (19.836 seconds)

    [01:54:58] [bDecode] Start: "O:\µTorrent\Beta\TAS\resume.dat"

    [01:55:08] [bDecode] End (10.113 seconds)

    [01:55:09] [TreeView Fill] Start

    [01:55:18] [TreeView Fill] End (8.807 seconds)

    [01:55:23] [bDecode] Start: "O:\µTorrent\resume.dat"

    [01:56:03] [bDecode] End (39.769 seconds)

    [01:56:03] [TreeView Fill] Start

    [01:56:39] [TreeView Fill] End (34.609 seconds)

    This was validated to be at LEAST 20% faster in 10 runs of each... can I do anything to help you figure out this excess shell calls which cause the processor to not efficiently be concentrated in BFE instead of the shell when filling treeview?

  9. Obligatory speed data ;) You'll notice some speed improvement... is this within expected limits?

    [23:59:14] [bDecode] Start: "O:\µTorrent\Beta\TAS\resume.dat"

    [23:59:23] [bDecode] End (9.732 seconds)

    [23:59:23] [TreeView Fill] Start

    [23:59:37] [TreeView Fill] End (13.809 seconds)

    [00:00:47] [Find/Replace] Made 851 replacement(s) in 26.288 second(s)

    [00:01:25] [bDecode] Start: "O:\µTorrent\Old Versions\resume.dat"

    [00:01:47] [bDecode] End (21.423 seconds)

    [00:01:47] [TreeView Fill] Start

    [00:02:21] [TreeView Fill] End (33.255 seconds)

    [00:03:16] [Find/Replace] Made 1899 replacement(s) in 49.244 second(s)

    [00:03:54] [bDecode] Start: "O:\µTorrent\resume.dat"

    [00:04:34] [bDecode] End (39.619 seconds)

    [00:04:35] [TreeView Fill] Start

    [00:05:34] [TreeView Fill] End (58.789 seconds)

    [00:06:53] [Find/Replace] Made 4224 replacement(s) in 64.755 second(s)

  10. Here's one batch.... cover13to15es4.th.png and here's the other bencodeeditorv26sl5.th.png

    Right click Save as, ^<-_first is 1.3 to 1.5 packed EXEs second is unpacked EXEs_->^

    You can find all of .6 in the thread. Also most of the old links still work. I can up anything else you want.

    All 20 RARs I downloaded are 4.984.105 ...

    1.279.094 packed RAR of the UNPACKED exe files is 11% of the 10.722.764 raw size. This compares to 2.367.559 packed RAR of the packed exe files is 45% of the 5.180.876 raw size.

    I farked up, and only included the filesizes/dates for comparison (if you can't read the filenames) into the larger packed RAR's comment.

    Ultima: If you don't want me making the unpacked EXEs available please tell me and/or edit the picture out :)

    From the notes here, yes the links are what you want. Un-rar the PNG. I'd unpack the 13to15 in a subfolder, as it's 20 folders. v2-6 can be in the current folder, it's only 20 EXE files. Also, NO I did not download the .2 ANSI... nor did I hear about this awesome thing when .1 was out. So unless Ultima provides it that's as far back as data collection can go.

    Edit: Removed ugly redness

  11. I was talking more of... time to find/replace over # of replacements.... and dictionary/list # vs size :P

    :D I like bar charts, so thanks for that hehe. Now make your own numbers... and compare. FTR: my comp is AMD XP 2000+ 768 MB DDR 400 if you want to start collecting stats.

    You'll notice that the ED values while easy to baseline due to their easy availability and free nature... Don't quite test the full variability of the display mechanism of BFE over time.... For instance it may take forever to decode a 500 KiB bencoded file with a dictionary with 20,000 keys, but display in an instant (or small fraction of the time it takes to decode). Comparatively decoding a 500KiB bencoded file with 100 keys & 200 sub-values may take exponentially less time to decode but moreso to display due to the sub-nodes BFE renders in the background (For reference my numbers previously 50,228K-4226x36 RED=RAM usage, BLUE=sub-root keys, GREEN=values per sub-root key)

  12. I haven't mentioned how useful the hourglass is >:D That's how I came up with my "find/replace" figures, if you didn't catch on.

    I still think it's to do with my limited RAM/CPU in this computer.. but if someone could come up with a function or curve demonstrating the performance times they see. My poor 1.5GHZ single core with 768 MB of DDR 400 doesn't cut it today apparently ><

  13. :P I already thought of the "merging" idea back when adding data was implemented... but then how does BFE import it(if there's no beginning 'd' and ending 'e' for dictionary... so I thought I would let sleeping dogs lie. :P It works well enough with Ctrl-X, Up, Ctrl-V, Down, Down
  14. Grr what did you change? Popped up in new posts >< This must be a mod option yes? That you make some changes and it doesn't update the thread, but others do.... pesky piksy pesternomi

    Edit: Obligatory test values

    [17:35:41] [bDecode] Start: "O:\µTorrent\Beta\TAS\resume.dat"

    [17:35:53] [bDecode] End (12.009 seconds)

    [17:35:53] [TreeView Fill] Start

    [17:36:13] [TreeView Fill] End (18.845 seconds)

    [17:36:38] [bDecode] Start: "O:\µTorrent\Old Versions\resume.dat"

    [17:37:12] [bDecode] End (33.857 seconds)

    [17:37:12] [TreeView Fill] Start

    [17:37:52] [TreeView Fill] End (39.634 seconds)

    [17:38:12] [bDecode] Start: "O:\µTorrent\resume.dat"

    [17:39:06] [bDecode] End (54.290 seconds)

    [17:39:07] [TreeView Fill] Start

    [17:40:07] [TreeView Fill] End (58.455 seconds)

    I have to say though I may have bitten off more than I can chew, I forgot about the size of the file >< Trying to use your "Value by Key" Find/Replace on 4226 items is... gonna take an hour by my count. It started at a speedy 42-48 replaces per second, then as the treeview grew (I assume) it's taking longer. It just slowed to 21 every 15 seconds after 12 minutes in. As an aside, I don't know what to do about this, but you can't cancel while "Replace All" is going on... so should the button be disabled? Or would you rather allow Cancel to interrupt the R.A. action?

    OK so it's done[18:54:05] [Find/Replace] Replacements made: 4226 Could we change the Windows "Alert" sound or whatever it is that plays when R.A. finishes ? Are there any other places where a sound is played?

    Dude, this is nifty, after any action which expands the treeview, sometimes it's just faster to reload the treeview instead of trying to use any other keybindings to mass change the display, because when it's loaded everything goes back to root display, nothing expanded.

    Edit: 186 seconds [20:36:16] [Find/Replace] Replacements made: 847.

  15. I have a theory the previous limit was 2^16 yes? With Unicode characters taking up 2 bytes per character that reduces it to 32768... In trying to figure out what else needs to be added, my only wish is you think of some way to be able to include both KEY and VALUE in Find/Replace ;)

    As far as treeview... Nothing appears out of place, perhaps if you say HOW you changed it it would be easier to test that. * expansion as well as double click and add/remove keys doesn't cause any irregularities I can see. And nothing appears to be different between .51 (even with my triple-scrolling vertical bar) resume.dat... so I think you're safe.

    Edit: More reverified fun stuff. c/o XIPH and lots of those lossless-philes http://orange.blender.org/blog/original-lossless-source-available/#comments

    0.6.0-B3

    [12:15:27] [bDecode] Start: "O:\µTorrent\ED-360-png.torrent"

    [12:15:43] [bDecode] End (15.978 seconds)

    [12:15:43] [TreeView Fill] Start

    [12:16:41] [TreeView Fill] End (57.449 seconds)

    [12:30:43] [bEncode] Start: "O:\µTorrent\ED-360-png.torrent"

    [12:31:12] [bEncode] End (28.743 seconds)

    That's encoding the file after adding an 3067 char comment to the (842,859 bytes) file. It has even more files than I've ever seen but still proves it's keys*subkeys which slows loading not the sheer depth of a specific dictionary or list. Consists of 15581 files. Average size=220.86KB of 3440896 KiB total dataset-size.

    0.6.0-B1

    [12:37:20] [bDecode] Start: "O:\µTorrent\ED-360-png.torrent"

    [12:37:35] [bDecode] End (14.704 seconds)

    [12:37:35] [TreeView Fill] Start

    [12:38:43] [TreeView Fill] End (67.646 seconds)

    0.5.1

    [12:41:04] [bDecode] Start: "O:\µTorrent\ED-360-png.torrent"

    [12:41:25] [bDecode] End (20.518 seconds)

    [12:41:25] [TreeView Fill] Start

    [12:42:48] [TreeView Fill] End (82.652 seconds)

    0.5.2 WIP 2/10

    [12:45:11] [bDecode] Start: "O:\µTorrent\ED-360-png.torrent"

    [12:45:37] [bDecode] End (26.007 seconds)

    [12:45:37] [TreeView Fill] Start

    [12:46:55] [TreeView Fill] End (78.002 seconds)

    0.5.0 WIP 1/20

    [12:49:32] [bDecode] Start: "O:\µTorrent\ED-360-png.torrent"

    [12:49:55] [bDecode] End (23.238 seconds)

    [12:49:55] [TreeView Fill] Start

    [12:52:03] [TreeView Fill] End (115.462 seconds)

    0.4.1

    [12:55:11] [bDecode] Start: "O:\µTorrent\ED-360-png.torrent"

    [12:55:35] [bDecode] End (24.106 seconds)

    [12:55:35] [TreeView Fill] Start

    [12:57:19] [TreeView Fill] End (103.828 seconds)

    0.4

    [12:59:56] [bDecode] Start: "O:\µTorrent\ED-360-png.torrent"

    [13:00:30] [bDecode] End (34.654 seconds)

    [13:00:30] [TreeView Fill] Start

    [13:02:14] [TreeView Fill] End (103.977 seconds)

    0.3 Aqua due to no internal timer in this version

    [13:06:15] [bDecode] Start: "O:\µTorrent\ED-360-png.torrent"

    [13:06:43] [bDecode] End <28 seconds>

    [13:06:43] [TreeView Fill] Start

    [13:10:48] [TreeView Fill] End <243 seconds>

    0.2

    bfev2ed1090sloadeddonewy3.th.pngbfev2ed790sloadedbf0.th.pngbfev2ed610sload3yb5.th.pngbfev2ed455sload3tn0.th.png

    bfev2ed305sload3ln4.th.pngbfev2ed160sload3qn5.th.pngbfev2ed160sload2xo2.th.pngbfev2ed105sloadxp8.th.png

    Pictures because there is no logging mechanism for it: Started 13:30, ended 33:20... But I counted it seemed only 1090 seconds to fill the treeview. I will say that the OLD method was much slower, adding and displaying as-decoded.

    It's also notable the memory usage of this old version is ~40% more at least for this test file. Barring inclusion of this version however the BFE has since increased efficiency by 100% :D

  16. If by "output" you mean testing export as binary or bencoded data.. I'm afraid I haven't tested that. I just went through the awesome scripting of loading each of my (moderately sized) resume.dat files 100 times.

    I did notice... there appeared to be a limit to "value" @ size 30000 bytes? I used multiple right click->paste in previous versions (as Ctrl-V doesn't work) and was able to pump it up to 30228... Is this expected? I can import for example binary data up to 155KiB (as that's the first thing I did instead of bencoded data when I was coming up with a way to restore old torrents from a resume.dat backup)..... If you could explain this arbitrary limit :D I'd appreciate the understanding.

  17. <poke poke poke> More poking at it :D

    Will report back in the morning after the stresstest.

    With my 3 most common testers :D

    50,228K-4226x36

    [16:16:19] [bDecode] Start: "O:\µTorrent\resume.dat"

    [16:17:02] [bDecode] End (43.297 seconds)

    [16:17:02] [TreeView Fill] Start

    [16:18:04] [TreeView Fill] End (61.008 seconds)

    39,312K-1807x50

    [16:23:18] [bDecode] Start: "O:\µTorrent\Old Versions\resume.dat"

    [16:23:46] [bDecode] End (27.882 seconds)

    [16:23:48] [TreeView Fill] Start

    [16:24:24] [TreeView Fill] End (35.701 seconds)

    24,368K-852x49

    [16:25:33] [bDecode] Start: "O:\µTorrent\Beta\TAS\resume.dat"

    [16:25:45] [bDecode] End (11.356 seconds)

    [16:25:46] [TreeView Fill] Start

    [16:26:04] [TreeView Fill] End (18.041 seconds)

    0.5.1

    [16:28:21] [bDecode] Start: "O:\µTorrent\resume.dat"

    [16:29:23] [bDecode] End (62.145 seconds)

    [16:29:23] [TreeView Fill] Start

    [16:31:16] [TreeView Fill] End (112.137 seconds)

    [16:33:38] [bDecode] Start: "O:\µTorrent\Old Versions\resume.dat"

    [16:34:15] [bDecode] End (36.713 seconds)

    [16:34:17] [TreeView Fill] Start

    [16:35:23] [TreeView Fill] End (65.955 seconds)

    [16:35:52] [bDecode] Start: "O:\µTorrent\Beta\TAS\resume.dat"

    [16:36:07] [bDecode] End (15.477 seconds)

    [16:36:08] [TreeView Fill] Start

    [16:36:37] [TreeView Fill] End (29.225 seconds)

×
×
  • Create New...