That was quick!

"since you are a new user your post will be hidden until it is approved by our moderation team.", urgh well 23 years isn't really that new I'd say.

See some of the old faces in here already. Nice to see you all!

The slightly weird thing that disturbs me about that is that firstName and lastName behave/look a lot like members of a class/struct yet don't have Pascal Case naming. name.firstName vs. name.FirstName It reminds me of Javascript, and well you know what that can inflict on the soul.

Regards, Rob Philpott.

Ah, Log4Net. From the glory days of .NET, as I moved from (work) place to place everyone used it. Seems to have lost favour in the Core world, and been replaced by something more standardised and flexible, but not as to-the-point :( Two line logging, whoever thought that was a good idea?

Regards, Rob Philpott.

Ha! Wikipedia, has an answer for everything doesn't it. Know-it-alls. Had no idea it was a documented thing. Interesting page, and I look forward to exploring the 'decision fatigue', 'existential crisis', 'information overload' and 'regret' links at the bottom! Right up my street.

Regards, Rob Philpott.

I'm not alone! Interesting idea about personalised databases. Where do you store the SQLite files, in a database? I guess the thing here is if you ever want to do a query that spans multiple users you are somewhat scuppered. I've always been interested in the idea that a SQLite database file lends itself to the loading, saving and transmission of application data, rather than a database per se, but never tried it out.

Regards, Rob Philpott.

I'm struggling with one of my hobby projects at the moment - I keep going down rabbit holes. I'm not exactly sure what features I want in it yet, I first need to come up with a rough prototype, some sort of 'minimum viable product' and let it evolve from there. Suck it and see. At the same time, in the back of my head I know there are requirements for it to be low latency, hugely scalable and fault tolerant, and this affects how it should be written. So I'll look at it and go, hmm 64bit references - too large, too much garbage collection overhead etc. So I'll remodel it all as unsafe structs in unmanaged memory. Then I'll think about memory mapped files - that could be a way of avoiding long loading and saving periods and good for fault tolerance etc. etc. Turning my C# into some mad C parody. Such efforts are kind of irrelevant in a sense as I don't actually have anything to scale out yet and hugely time and thought-consuming and generally stalls the whole thing. In the end I'll probably just get disillusioned and abandon it, like so many other projects. I've written down on a piece of paper on my desk 'No Rabbit Holes!' but I really struggle writing stuff that I know isn't taking into account nasty things down the road. Rabbit holes - they're like magnets. Trying to think too far ahead is perhaps a tendency that kills things dead. Does this ring bells with anyone?

Regards, Rob Philpott.

A bit late to the party, but here are a few thoughts. String manipulations are as you say possibly the most likely bottleneck. Strings are immutable in C# (they don't change), so if you concatenate two strings it involves copying the data from both of them into a new string. If you're doing this in a tight loop there's going to a lots of work (and garbage collection) involved. For building up strings, StringBuilder is the class of choice, and for substrings etc. you could look at Spans ([C# - All About Span: Exploring a New .NET Mainstay | Microsoft Learn](https://learn.microsoft.com/en-us/archive/msdn-magazine/2018/january/csharp-all-about-span-exploring-a-new-net-mainstay). If your files are large, take a streaming approach. For instance File.ReadAllLines() loads everything into memory where as File.ReadLines() returns an iterator where you just deal with the current line. Reading a massive file into memory often isn't a great idea. With those in place, the only other thing I can think of is pipelining. Have one thread read the input file and present records via a queue to a processing stage which processes them and then submits them via a queue to a writing stage. All these stages can run concurrently. TPL dataflow is the thing for this. Finally, if you are using Parallel processing for nested loops, make sure you do it on the outer loop. There is overhead in parallelising work and you get better performance that way. It's all rather difficult to say without seeing the code!

Regards, Rob Philpott.

Sounds like digital hoarding! How many copies of copies of things do you have going on? I'll create a back up of something, then that'll get backed up into another folder, then that PC will be upgraded and I'll copy the whole thing into another folder which will get backed up, then onto another disc in case the first blows up. It's the digital equivalent of a garage full of stuff you're too afraid to throw away in case you may one day need it. Yep 2x 4TB drives full of garbage in my PC currently. 16TB is really quite a lot when you think about it..

Regards, Rob Philpott.

Richard Deeming wrote:

detectable infinite loop

Classic! You won't find any of my switch statements without one of those. :)

Regards, Rob Philpott.

ReadOnlySpan bytes = "ABCD"u8;

You see, I had no idea you could do that. u8 - when did that arrive?! Can't keep up with it all.

Regards, Rob Philpott.

Maybe, that thing is old, predating generics so there might be some boxing overhead depending on what you stick in it, unless they've done a generic version of it. It's hard to comment from this distance, but if the state machine _might_ change, surely its better to model it at runtime so you just need to adjust some static data rather than go back to source... Profiling is always a good option, to see where the bottlenecks lie. Anyway, best of luck! :)

Regards, Rob Philpott.

C# has gone a bit bonkers hasn't it? I still have to look up how to do this 'new' stuff. Although I do like being able to create empty arrays with [] etc. Oh, and I think you're out-by-one: return input[18] switch

Regards, Rob Philpott.

Ah ok, so is it that you've got these large files to process and you're trying to optimise the switching (state changes) for speed? Which approach are you using at the moment (switch vs. array lookup/not dictionary, sorry just read your update)? I suppose another difference is that switch statements are compile timed things, turned into code, whereas dictionaries are created and used at runtime. Does this mean the switch/state change logic is fixed in advance? I think the only well to tell really is try both methods and see which is quicker (if noticeably so). What I would say is I'd expect them both to be fast, so is this really the bottleneck to performance gains, or could something else be optimised? Multithreading/pipelining etc. TPL Dataflow (if you're in .NET) is good for this.

Regards, Rob Philpott.

Interesting question, to which I wouldn't like to guess the answer, but here's what I'd consider. Firstly, what is it that is being switched? If its something primitive like an integer, the switch code would I expect boil down to a collection of CMP and BEQ instructions (compare and branch). These would be stupidly fast, and because they are consecutive in memory are likely to benefit from CPU caching, so in that instance, an awful lot of switch cases could be compared in the time of a dictionary look up. If you are switching on strings though, things get more complicated. To do the dictionary look up, first the string needs to be hashed to give a bucket index, then an equality check is needed to make sure it matches. The switch statement doesn't need to do the hash, but has multiple equality checks to do, so I suspect the answer here boils down to the ratio of time taken to hash vs. time taken to do an equality check. So then you get into the realms of how similar are the strings? To check for equality, if the first character is different you can just bail out and fail the test quickly, but if its the last you have to go through every character before you can pass or fail the test. It'd be interesting to profile this, but somehow the idea of creating a switch statement with hundreds/thousands of cases sounds unpleasant, I have no idea whether a compiler would accept it and would be completely impossible to work with.

Regards, Rob Philpott.

Aha! I should, perhaps, read the documentation sometimes, what with it being the first sentence and that. The crazy lengths we are forced to go to stop mitigate people attacking our software...

Regards, Rob Philpott.

You know, I hadn't thought of that. By design, so that weirdness comes out early rather than later. Sounds like something the Rust brigade would do - good thinking!

Regards, Rob Philpott.

Good morning CodeProject! I’ve decided to teach myself something new - apparently it’s important for older people to do that to stop them going mental. So behind the back of my loving, dependable and reliable C# I’ve been having a risqué affair with Rust. Turns out that developing in Rust is about 30% expressing your intention in code and 70% arguing with a bad-tempered bureaucratic compiler for who simply nothing seems good enough. I decided my first project would be a Suduko solver, which is done and it works, but there was an interesting point in the development where different runs would dish out differing results. I was using a HashSet internally, and like in .NET you shouldn’t make any assumptions about the order of the items if you iterate over it. Fair enough, but I would expect it to be consistent in that ordering between say releases of the .NET framework. Not so in Rust. Here’s a Rust program:

use std::collections::HashSet;

fn main() {

let mut set = HashSet::new();

for n in 0..5 {
    set.insert(n);
}

for n in set {
    println!("{}", n);
}

}

And here’s the output from running it twice: 0 3 2 1 4 and 0 2 1 3 4 Interesting huh? Something non-deterministic is going on. I haven’t debugged the HashSet yet to find out, but I’m presuming it’s using some random number or aspect of time somehow. I spoke with 'Gemini' about it yesterday and it agreed it's interesting, so thought I'd share it. :)

Regards, Rob Philpott.

Yeah, that 230v is a misnomer. It's still 240v but we label everything as 230v and add a tolerance to harmonise with Europe's 220v. So we've got 240, they've got 220 and we all call it 230! 50Hz. Ah, the 50Hz hum. You get to recognise it, whenever a jack plug isn't in properly or something. I've not heard the US 60Hz, but I guess your mains hum must be a couple of semitones higher (I could work it out, but can't be bothered!) 1800W - that's not a lot. So the most common fuse here is 13A which gives an appliance circa 3KW. I'm told that a 13a fuse will actually blow at about 20 amps. My ovens require a 16A fuse, but I've just stuck a 13A socket on them and they work fine, which is handy as otherwise I'd have to go all the way back to the consumer unit. I, and probably some other weirdos, feel some affection for our 3 pin plug. It heralds from a time when the UK did things properly (now we just do everything as cheaply as possible or better yet import it). The earth pin is longer than the live/neutral, and the extra length opens shutters in the socket which prevents kids sticking metal things in the sockets. Everything is fused and earthed. It's very good! But coming back to the 120v, I wonder what that feels like. Having had more than my fair share of connections to 240v, I can say it certainly wakes you up (at a minimum). Actually, I had a near fatal shock when I was six where I couldn't let go which burned a hole in my hand. 240v is lethal, your chances have to be much better at 120v, so maybe the need for all the clever stuff of the three pin plug isn't needed. I don't know why I find all this so interesting.... :)

Regards, Rob Philpott.

No fuse? Two prongs? 120V? I don't really get any of these things. Here in the UK every plug has a fuse in it, every plug has three pins (not always used for 'double insulated' appliances) and a punchy 240v flows through those terminals. No fuse? Why doesn't everything burn down with electrical failures? No earth, how do you protect metal items? 120v - So you need twice the current/twice the area of wire per watt? Do you have RCD protection, so any earth leakage will cut the power? I take your point!

Regards, Rob Philpott.

Richard Deeming wrote:

Ha! At our old house, gas and electric combined was close to that per month!

Ouch. That's serious.

Richard Deeming wrote:

so they're paying us over £570/month for that

That's insane, and quite interesting. I know a few people who have panels and the gist of it seems to be they can sell 1KWH for 10p or something, then buy it back later at 35p.

Regards, Rob Philpott.