1

I previously ran into an interesting practice called occlusion culling in game development. I am still researching to gain more understanding of how it works, since this is mostly discussed in game programming/tools/IDEs such as Unity, so I am applying the practice to data management in application development.

Other names for the practice as defined on the wiki here: Surface determination (also known as hidden surface removal (HSR), occlusion culling (OC) or visible surface determination (VSD))

My understanding of the practice is that when rendering 3D graphics, an algorithm is used to determine what objects should be rendered, and in memory, based on some view/camera perspective. This is mainly used to use graphical memory more efficiently, but it does not necessarily make non-graphical memory usage more efficient, as the data behind the non-rendered objects is still being manipulated.

As for applying the practice, I am attempting to use the aspect of managing data loaded during run-time of an application, where the data could be rows, specific values, or some object.

From an application standpoint, this appears to be similar to either some form of lazy loading or stateless calls/events.

private Lazy<Foo> DataItem;
public void GoToNextView()
{
    DataItem = new Lazy<Foo>();
    //return data to some display
}

For the above example, the previous data would be cleared/set for garbage collection via the new constructor, then there would be potential new data to be loaded.

Here is a specific example:

For some paged table, there is only data specific to the page loaded, then on "Next" the previous page is unloaded and the new page is loaded. this practice lends itself to be more event-based in my mind, and that is mainly due to thinking in terms of the UI/frontend aspect of an application. Unless doing data manipulation from the codebehind of some UI, I cannot see a good example of using lazy to help in data management, since the UI would be loading the data more immediately rather than wait for a specific step. (please correct if my understanding is not correct between lazy loading and stateless)

From a framework/custom library perspective, I believe that there could be more differences between the two practices, since there is the potential for more instances of data manipulation and incremental steps that can precede certain data loads.

private Bar DataItem;
public Bar Process()
{
   DataItem = new Bar();
   //return some processed/manipulated Bar value
}

private Lazy<Bar> OtherDataItem;
public Bar OtherProcess()
{
    OtherDataItem = new Lazy<Bar>();
    //process other items
    //at some step, get the value associated to the variable via OtherDataItem.Value
    //return some processed/manipulated Bar value in respect to the other processed items
}

In this case, there is a difference in data management, where the first will hold the full data associated to the type from beginning to end (end being either end of the method or disposing/garbage collection). From my understanding of lazy, the data will not actually be retrieved until the Value is called, so the data would not be held from beginning to end (I believe that there is also a check in the background for disposing unused data for lazy types, and I do not know if that is true or deals with some other specific thing).

I am looking for practices in application development that achieve the same goal of data management based on being in focus like the practice seen in game development. I do not know if there is a chance that this is actually a tool rather than a practice, since research tends to lead me towards usage in Unity.

For my question(s), what application development practices actually fall within the data management practice shown in occlusion culling from game development practices? If the above two specified application development practices are equivalent to that game development practice, then does the understanding that I am trying to convey appear accurate?

Again, I am still researching and diving into any information that I can find, and my knowledge may not be correct on either side (application or game development). I feel that I am at a point, where I need to have a check on my understanding before committing to that idea and advancing. I welcome any corrections or questions to my understanding.

  • Thought experiment: does a web page appear to load faster if you require that all of the data be loaded at once before the page is displayed, or if you load the data incrementally and generate portions of the page as the data loads? – Robert Harvey Feb 28 '18 at 22:41
  • From a .Net perspective, I have found that the main driver in data load speed has been network traffic and the security in place, but I have seen significant slow downs when using table structures based on custom objects that are in a hierarchical structure, like scheduled appointment header with event information lines. Usually, I have seen cases where everything is loaded to perform mass changes or follow certain rules, like not scheduling two items at the same time. There are better ways which lend itself to only loading/using what is necessary. – eparham7861 Feb 28 '18 at 23:06
  • Incrementally, the difference in speed is negligible for navigating the pages, but can be seen when operation to a database or web service. The downside is handling post backs more efficiently, otherwise there is some confusion on what part is slow at that point. That has just been my experiences so far. There are other things that I have not hit yet to understand. – eparham7861 Feb 28 '18 at 23:10
  • 1
    Sounds like you might be overthinking this. My question wasn't "which approach is faster or more efficient," it was "which page appears to load faster?" – Robert Harvey Feb 28 '18 at 23:13
  • In any case, I can see how lazy loading might make room for other processing operations to take place while data retrieval is deferred, making for a smoother experience overall. – Robert Harvey Feb 28 '18 at 23:14
4

You're trying to generalize what you're learning. This is good. It shows you're trying to do more than learn by rote.

Occlusion culling is fairly similar to the caching problem. You have to limit use of limited resources. Do it correctly and there is a big payoff. Do it wrong and it's very costly. What makes it different is how you predict what won't be needed.

In applications you have resources that operate at different speeds. Local is faster than remote. Memory is faster than the hard drive. But only so much can be kept local and in memory. You have to anticipate use and have ready what is most likely to be used next. Get it wrong and things get slow.

You see this sort of thing even when opening a text file. The scroll bar shows you that there is more here then what you're looking at. But since the screen is only so big you aren't looking at the rest yet.

Some text files are big enough that you're wise to only open them using a special text editor because the people who wrote the typical editors had an idea of what a typical file size should be. Because of that they thought it would always be OK to load the whole file into memory. Not cool if your file is bigger than your memory.

  • As far as approaching this from the caching problem, would there be many arguments/points, or any at all, where the business constraints/rules/logic would not be the main focus in defining those limits? For example, a web page to display general ledger information against filters, and a feature would be to drill down to a specific item sold and its costs via some collapsible region. The amount of data should be limited by the filter, and the collapsible region. Those features provide the idea of a boundary, are there any non-functional features that provide the same boundary/map concept? – eparham7861 Mar 1 '18 at 15:41
1

As mentioned in other answers, the things that are the same between the scenarios you mention is that you're attempting to reduce the data set you have to work with at any given time in order to improve the speed of interaction. This is done in many different cases.

One thing to keep in mind is that you need to first profile to see why the speed isn't what you want. Profiling will tell you where the time is being spent and either allow you to speed up that part or know if you've hit a limit and maybe need to try a different approach.

It could be that the issue isn't how much data you have in memory, but the way it's arranged in memory, or some other feature that you haven't thought of. Or perhaps the display routines are what's slow, and your arrangement of data is just fine and you can actually process it all fast enough. Until you have decided what your goal is and then measured to see if you're hitting it, you shouldn't worry so much about how to fix it. You could spend a bunch of time making a great new algorithm only to find out you've optimized the wrong part.

  • Very true. In some of the cases where I would like to apply these ideas, there is a significant slow down between operations for web pages. There is also an increase in how much speed is lost when running locally/debugging (upwards or 5 - 15 second loading times for first load and any post backs). I am completely lost on the idea of profiling, so I will look into that more. From a development standpoint, what does it mean to have data arranged poorly in memory? – eparham7861 Mar 1 '18 at 15:46
  • You ask, "From a development standpoint, what does it mean to have data arranged poorly in memory?" Think of it this way - unsorted data requires a linear search to find a given element. Sorted data can use a binary search and find it in log(n) time. Which arrangement is best for you depends on what you're trying to do. It can also depend on the machine that's running your code. Things like CPU cache size, amount of RAM, network speed, etc. all affect performance and can help determine optimal memory layouts and also determine limits of performance. – user1118321 Mar 1 '18 at 17:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.