xyz Yeah, I think you're right. Initially I was getting faster times, but then I converted everything to use Dictionary[CustomResource] again and the loading time was the same. So it may have been that my PC slowed down in my first tries, and it got faster by the time I finished converting everything to Dictionaries. Now I converted everything to resources again to test it and yeah, times are pretty similar (sometimes one method is faster, sometimes the other is faster. It may have to do with my PC).

So to be clear, Godot also initializes everything inside Dictionaries just as it does with variables?

  • xyz replied to this.

    Godoten So to be clear, Godot also initializes everything inside Dictionaries just as it does with variables?

    Well to put it simply - yes. You can't get away from loading the data and spending time on it. It doesn't really matter in what type of structure you hold that data once it gets from disk to memory. So the comparison of dictionaries vs resource objects in terms of performance the way you've framed it here doesn't really makes much sense.

    If you want more specific advice on how to handle some structured data, post the exact use case.

    Godoten Answering this question without knowing what you are doing exactly is a bit tough. But the best way would be just measuring it, as is usually the case with questions about optimizations. Shouldn't be too hard to mock some plausible data and build a simple project around it, I would assume? Then you can compare both.

    But I would raise another question that might actually be more important: How are you going to edit this data? Depending on the amount of data that you need to edit I would assume that you don't want to end up creating and editing everything in code but use a more comfortable solution like a spreadsheet or custom made UI instead? Then the question becomes "How do you import this?". Maybe as a CSV table or a JSON file? The answer to this could significantly influence your decision on how to store all this information.

      i have been playing with storing, saving, changing, loading, and checking that data stays with its original scene(pointers) in my current project. Each resource individual to each scene.
      Changing data in anyway to the script has almost no effect on performance. The only performance issues i could create was when running
      many hundreds of scenes on screen each with complex physics operations.
      Saving and loading was again instantaneous regardless of how many resources i touched.
      When altering the data in scripts, even when rendering "too" much the data transfer and adjustment was light speed, negligible from doing the changes with few scenes.
      I really don't believe data to be that large of a bottle neck. more so the way it is parsed and instanced. such as, If my code was better i could run thousands of scenes at the same spec.
      Under the hood, i think the dictionary is used as just the same resource in Godot. I could be way off with that understanding tho 😛

        REVBENT Well, from what I could take from the docs, Objects are definitely slower. I'm assuming Resources are Objects since they inherit from RefCounted > Object. Certain operations are faster using Array or Dictionary rather than Object since they don't need to check the scripts nor classes.

        Whether those faster times are even noticeable I guess it dependes on the game and the machine. Ideally, I would like my project to run in as many machines as possibles, including smartphones. And I think learning this for my "hobby" project will help me for my more "serious" projects.

        Toxe I did some testing but my machine is not consistent (it's an old PC) so the results varied: sometimes Dictionary was faster, other times Resources were faster. Resources are clearly easier to manage, but I made a custom "manager" with a custom UI to add and remove data in real time, so that's not a problem. I was looking for the fastest data container to load and run. Using Resources as dictionaries may seem like an overkill when you will not use internal operations. Even if you won't notice the difference in most projects wont, I want to use the best practice so that I'm ready for any project.

        About "how to import it", I used a single Resource to import all the dictionaries (instead of a Resource containing Resources). That's the system I'm testing right now!

          Godoten slower... faster

          What do you mean by this? The speed of what exactly are we talking about? You can't just confront dictionaries vs resources in general. It makes no sense without specifying what aspect exactly are we comparing and in what context.
          Perhaps post some actual code you used to compare the two.

            Godoten I did some testing but my machine is not consistent (it's an old PC) so the results varied: sometimes Dictionary was faster, other times Resources were faster. [...] Even if you won't notice the difference in most projects wont, I want to use the best practice so that I'm ready for any project.

            How much data did you try? If you want to measure/benchmark it's usually best to let your code run for a longer time. What "longer" means depends on your circumstances of course. In your case of loading lots of data files maybe 10 to 30 seconds? So create... I don't know... 100,000 files? And/or perform more than one run and calculate the mean duration (and bonus points if you calculate the median). If you still got no measurable difference outside the margin of error then it didn't matter and you can pick whatever you like best.

            xyz I tried before but my code doesn't make sense without the whole project (and I still don't understand how GitHub works, although I want to learn).

            What I mean about Resources being slower in some operation is this from the docs:

            Every time it performs one of these multi-source queries, it runs through several iteration loops and HashMap lookups. What's more, the queries are linear-time operations dependent on the Object's inheritance hierarchy size. If the class the Object queries (its current class) doesn't find anything, the request defers to the next base class, all the way up until the original Object class.

            so using has()is not really efficient (for what I can understand), just like using "find" on Dictionaries/Arrays. My use case for a chat system (kinda like the one in Habbo, but where chats become interactive) would be:

            1. A container that stores containers of data (chats). For this container I can use a Resource (let's call it BaseContainer) with an Array since I will need to iterate it at the end of the match and process the data (Array is perfect for iteration If I understood right).
            2. The data container, which apparently can be either a Dictionary or a Resource since I will be accessing the data in real time using a custom system that modifies and saves them (players can use resources to modify other people's chats in order to "sabotage" them).
            3. I need a way to put together multiple "BaseContainer" in order to iterate one after the other is done, but the next "BaseContainer" would be decided based on the result of the match. It's hard to explain without the whole project, but I'm working on making "BaseContainer" to be able to iterate the Array it contains, and then attach a second array if there is one to attach after it's done iterating. So at the end I will have a single BaseContainer that can hold everything, even other BaseContainer.

            So those are the basic operations I will be using: iterating and accessing variables (or keys), as well as somehow dynamically attaching arrays together.

            • xyz replied to this.

              Godoten I thought we were talking about loading data from disk. Apparently the subject changed.

              Anyway, dictionary lookup may be comparable to object lookup in GDScript. So it likely wouldn't matter with the data quantities you'd have in practice. Are you sure you're not engaging in premature optimization here?

              It's hard to talk abstractions. If you want a specific suggestion about how to organize the data architecture, describe what are you making in simple terms. How does it look from the player/user perspective. Otherwise, if you present only your attempted abstract solutions, we have no way of knowing if you choose the right architecture or approach for the actual problem. We need a description of the problem, not what you tried so far or how you think it should be done. That can just drag the discussion down some long but wrong alleys, wasting everyone's time.

                xyz Although my initial question was about loading data speed (which seems to be about the same), @Toxe suggested it's important to consider how I would edit the data and @REVBENT said changing data in the script had no effect on performance in his tets, which made me consider what would be faster for the rest of the process.

                And I'm focusing of optimization because I want to learn for bigger projects. But also, I have a pretty old PC and I would like my game to run fast in a lot of devices.

                We need a description of the problem, not what you tried so far or how you think it should be done.

                Makes sense. My initial problem was: "Given that a container will hold all the data from a match, even other containers like itself. What is the fastest way of loading this data (knowing that you won't need all the data at first, just a few initial elements) while ensuring that the iteration process will be fluid in as many devices as possible".

                But I think it was answered since Dictionaries also need to initialize their content (for example, if a dictionary has a "myKey": CustomResource.new() it would need to initialize the CustomResource and its variables, including other internal resources. So in theory, there should be no difference between a dictionary and a Resource, unless initializing the base classes (like Object and RefCounted) took too long.

                • xyz replied to this.

                  Godoten there should be no difference between a dictionary and a Resource

                  Precisely what I have been telling you from the start. Objects and dicts both use hash map lookups. So it is to be expected the lookup performs almost identically. You may have so little data (relatively speaking) that any optimization won't be necessary. If a bottleneck still shows up, then switching from dicts to objects likely wouldn't make any difference. You'd either have to optimize the algorithm, delegate the bruteforce load to native code or distribute to threads. So overthinking this dilemma you've put up is pretty much a waste of time.

                  Btw, you still haven't clearly described what you're building. "Container" is an abstract concept that still belongs into the solution domain not into problem description domain. I don't know the game you're referring to so just mentioning it may not be enough. Describe what you're building, in detail but without any technical or programming terms, if you want an optimal solution suggestion that is.