r/dotnet • u/mightyAS1907 • 2d ago
Newbie Created a structured repository to practice C# Data Structures & Collections — Feedback welcome!
Hi everyone!
I'm an IT student focusing on C# and .NET core fundamentals. To build a strong foundation in backend engineering and memory/performance concepts, I created a hands-on repository covering various C# Data Structures and Collections.
What I've covered so far:
• List<T> & Reference Types
• LinkedList<T>, Stack<T>, and Queue<T>
• Hashtable, Dictionary<K,V>, SortedList, and SortedDictionary
• SortedSet<T> & HashSet<T> (Set operations like UnionWith, IntersectWith, etc.)
Each module includes sample code and a quick breakdown in the READMEs. I'd love to hear your feedback or any suggestions on code style and performance optimizations!
GitHub Repo: https://github.com/24alpserdar/csharp-data-structures-and-collections
1
u/AutoModerator 2d ago
Thanks for your post mightyAS1907. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/BotJeffersonn 2d ago
I agree with brianluong.
Since you focus on "backend engineering and memory/performance concepts" I could recommend CS50 X as a course for you to either enroll in or watch the lectures. Gave me a solid understanding of memory and how things actually work under the hood.
Basarilar
1
1
u/QWxx01 2d ago
Good job on learning this way. It teaches you valuable insights by doing. Do you know about Benchmark.NET? It's a library that allows you to benchmark code to see which variants run fast (or not), this is especially relevant since you're interested in performance.
Check it out at https://github.com/dotnet/benchmarkdotnet
2
1
1
u/Tezshouse 2d ago
Nice way to organise the learning. One thing I'd add as you go deeper is a small comparison table for each collection covering average/worst-case complexity, allocation behaviour and memory/cache locality, rather than complexity alone. For example, `Dictionary<TKey,TValue>` lookup is generally O(1) "average case", whereas `SortedDictionary` gives you O(log n) with ordering. `LinkedList<T>` is also a good example of why Big-O isn't the whole story, even though inserting/removing a known node can be O(1), the extra node allocations and poor cache locality can make `List<T>` substantially faster for many real workloads.
Since you're specifically interested in backend performance, I'd probably make the next exercise, implement a minimal version of two of these structures yourself, then benchmark the custom implementation against the BCL version across 10, 1,000 and 1,000,000 items with BenchmarkDotNet + MemoryDiagnoser. That gets you from "I know how to use the collections" to understanding why you'd choose one over another, which is the really valuable bit. Hope this helps!
2
0
u/cutecupcake11 2d ago
One of my recent interview questions was to build a linked list from scratch using base types/classes without using any other imports..
Trying to understand how the building blocks work for learning purposes would take you ahead...
2
9
u/brianluong 2d ago
Your heart is in the right place but I'd recommend following an actual data structures & algorithms course. From a quick look you're simply using the data structures already built into C# and throwing a tiny amount of data at it to, I'm assuming, learn syntax? Following a course, even in a different language, will teach you a lot more than what you're doing in this repo.
If you don't feel like following a course try implementing something that actually stresses your DSA knowledge. Build a write-ahead log, b-tree, text editor, json parser (NOT using built-in json parsing functions), etc. and ideally throw copious amounts of data at it so you can see when your structures break. The performance characteristics and tradeoffs are what you're trying to learn. That won't "stick" unless you throw real data at the system and watch it bog down, at which point you profile the problem, re-architect it, and measure again. That's where the learning happens.