BEncode Editor

[jewelisheaven]

Here's one batch.... and here's the other

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

[Ultima]

Short answer: The Find/Replace slowdown had nothing to do with system specs. It was due to (1) the way a particular built-in AutoIt function is implemented, and (2) my laziness in writing a "proper" solution. (Yes, that means I knew about the slowdown all along -- general laziness indeed)

Long answer: In treeviews, there is no normal way to find a node's index other than to manually count it. As things are implemented, I use node indices to determine what BDecoded item to edit, and what treeview node to jump to when an item is found. For small trees, this isn't normally a problem, but as the tree gets larger and larger, you'll notice significant slowdowns because AutoIt is repeatedly counting the treeview nodes to get the correct index (or to translate an index to the right treeview item). That's why, as you get further and further, you'll notice the treeview jumping to the next item more and more slowly. The slowdown was all in the treeview manipulation. That happens because I was too lazy to keep track of indices myself (which, if I did, would prevent the need to recount every single time just to go from one node to another adjacent node).

Analogy: Imagine reading a book where, in order to go onto the next page, you first have to re-read all of the preceding pages, all over again. Yeah. Annoying as hell (and quite obviously, slow).

That said, "was" is the operating word.

http://www.savefile.com/files/1530830

Changelog

~ Change: Add accelerators for dialog buttons

~ Change: Disable dialog buttons on action

~ Change: Faster Find/Replace operation (much improved on larger treeviews)

Simple tests on various files with many keys showed at least a 90% improvement in speed, but obviously, it all depends on how many items there are in the treeview to begin with. I also introduced a bug in find/replace in the last WIP. I'm surprised no one ran into it, but uh, cool -- it's fixed now anyway. Finally, I added a timer for Replace All, because timers are cool. And stuff.

NOTE: By my tests, treeview updating and jumping now accounts for approximately half of the total amount of time spent on Replace All (it probably used to account for 95% of the time). Still, I'd prefer that over reloading the treeview, regardless of whether or not the net amount of time would be less with a purely internal search/replace, then reload. That's ugly.

---

Merging... I've been considering it since forever, but at this point, it doesn't look too likely that I'll be implementing it. Then again, I've said that about a ton of features before that eventually got added. *shrug*

Multiple selection gets a big fat "no," just because there is no way to select more than one item on a normal Win32 treeview anyhow.

[jewelisheaven]

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)

[Ultima]

O_o

I'm quite certain I didn't touch decoding or treeview filling... Those speed improvements most certainly are surprising. Can you test to make sure nothing was b0rked in either process by comparing with... say, a stable version's treeview (and "editing" a few random items to make sure their contained values still match)? I'm suspicious...

[jewelisheaven]

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?

[Ultima]

I meant process as in BDecoding process and Treeview Filling process. I'm not really sure what you're referring to when you say "shell." Or what you're referring to when you talk about CPU usage differences. At any rate, if there aren't any differences between what's loaded/parsed/shown, I guess the speed difference doesn't really matter

[jewelisheaven]

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.

[Ultima]

I'm not really sure what you're referring to when you say "shell."

[jewelisheaven]

Explorer or blackbox (http://bb4win.org) both show CPU usage only when treeview filling.

[Ultima]

*shrug* I don't really see any reason why the desktop shell should affect how an application runs (or where the CPU usage goes). Meh.

[jewelisheaven]

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 :`(

[Ultima]

Nope, I don't keep track of the position in the file.

[jewelisheaven]

Esoteric: How does it know there's an error? Or is just because you don't log position doesn't mean you don't keep track of the nesting of keys.

[Ultima]

It knows that there's an error if it hits something that it doesn't handle. I don't keep track of recursion depth either, though I probably should. That thread is probably why The 8472 suggested that I make the decoding iterative, but as I mentioned earlier, I still can't wrap my tiny brain around how I'd do that efficiently.

Oh, as an aside...

~ Change: Unicode support on treeview and listview

[jewelisheaven]

You mean no more ... when it's non-ascii? AWESOME

[Ultima]

Yeah, it'll display even when there are non-ASCII characters now, but only if it doesn't run into any problems converting from the binary data to string data (which generally happens if the data gets truncated on conversion to a string due to it hitting a null byte). The non-ASCII thing itself wasn't the (real) reason Unicode wasn't supported before (that is, even if I didn't limit what could be displayed, Unicode characters still wouldn't have been displayed properly). The reason was that I was using non-wide character API calls (*A rather than *W) to create the treeview/listview items.

This means it'll have an ugly display on binary data that doesn't contain null bytes, but does contain lots of other random characters. That's the tradeoff you'll have to deal with, I guess.

[andron]

Hi! When searching 'Value by Key', can you implement a wild card search for the value? Say, I want to find an 'uploaded = <anything>' key.

Hope you will not get an 'overflow' from our requests.

Kind regards.

[Ultima]

I would, but then how might I differentiate between a search for a wildcard, and a search for the actual character(s) that comprise the wildcard?

Then there's always the possibility that I can let a blank search field be considered "anything," but then what do I replace when using search/replace with a blank? The whole thing?

Then there's also allowing regular expressions, but then how would I replace binary data using regex?

[jewelisheaven]

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

[Ultima]

I can't differentiate between binary data and strings -- strings are binary data :/

[jewelisheaven]

o.O but ... >< inDEED. As usual my mouth needs to catch up to the brain (I never processed all strings were (... 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.

[GTHK]

when changing the name of a list, the marker changes to integer, even though it's still a list. And when trying to edit it again, it says integer, even though it still has values as if it were a list, and trying to change it to list deletes everything in the list.

[Ultima]

Mm... nice catch. That happened here due to the many underlying changes I made. Thanks, and keep 'em coming (assuming there are any more regressions)

@jewelisheaven: Unicode input/output has always been possible -- it just didn't display Unicode in the treeview and listview because of a limitation in AutoIt that was lifted somewhere along the way.

[GTHK]

No problem, I am here to test (this and µT ). A side note though (in case it's important), as a result of it, trying to delete a binary string in the "interger-list" results in some AutoIT error.

[Ultima]

Yep, that's because the list actually gets overwritten with an integer when the problem occurs. Since the treeview goes out of sync with the actual data, the treeview still thinks there's something there in the "list" (turned integer) when in fact there's nothing (because it's now an integer). As such, it'll run into array bound issues. It should no longer be a problem now that I've fixed that regression