LDraw.org Discussion Forums
coding a quick inline process in .NET (visual basic) - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Off Topic (https://forums.ldraw.org/forum-28.html)
+--- Forum: Off-Topic (https://forums.ldraw.org/forum-27.html)
+--- Thread: coding a quick inline process in .NET (visual basic) (/thread-13255.html)



coding a quick inline process in .NET (visual basic) - Michael Heidemann - 2014-06-22

Hi Guys,
I hope the apps that I could provide in the past are helpful for your work.

Now I think I need help from your side, if you are a coder. Please note that I am only able to code in .NET (visual basic).

For some applications I need the inline procedure (f.e. grafics output). Because the code I currently have is up to 10 times (or more) slower than the code Philo uses for edger2, I like to know why and what I need to change.

I have stopped my development for a viewer, because it does not make sense to wait a minute to see a 2 x 4 Brick Sad.

I already tried to do this myself, but failed ever time. Now after about 2 years I think I ask the public.

So, if there is somebody who reads this and like to help, please let me know. We can discuss in this thread or by PM. I am open for every communication.

cu
Michael
[mikeheide]


Re: coding a quick inline process in .NET (visual basic) - Roland Melkert - 2014-06-22

I'm mostly a Delphi/c++/php programmer but I'm willing to help.

Does inline means something different in .net? Cause I don't think forcing functions to inline (which isn't even possible in .net I think) would give you a 10x performance increase.


Re: coding a quick inline process in .NET (visual basic) - Michael Heidemann - 2014-06-27

Thank you very much for your feedback.

I am talking about the inline process of ldraw files. So every author that has already written a viewer for ldraw files has an inlining tool, as base elements needs to be given as triangles to the renderer.

I know from another experience during my coding with .NET that some build-in function are quicker than others. This might be .NET relevant, but could also occur in other languages. I do not know.

My feeling is that using functions does slow down the application, because each function has some overhead that also needs to be executes while the app is running.


Re: coding a quick inline process in .NET (visual basic) - Travis Cobbs - 2014-06-27

Unless I'm misunderstanding you, that's not true. Properly written LDraw-file-loading code definitely does not inline, and if you are inlining, it may explain the performance problems you are having. For example, when LDView loads an LDraw model, it reads and parses each ldraw file in the part library that is referenced from the top-level file (or any sub-file) exactly once. When the same file gets used in another location (which happens a lot with primitives), it simply refers to the already-instantiated object in memory that has already been created for that file.

This was actually somewhat difficult to do in C++ in 2000 when I started LDView, since C++ didn't really have good reference counting. (The std:Confusedhared_ptr class that handles reference-counted pointers was added in C++11, I think. I implemented my own reference counting.) It's much easier to do in C# and VB, because both of those use Garbage Collection, which takes care of the problem.

In order to render the model, you simply walk the tree. LDView flattens (inlines) parts when transforming the part data from an in-memory format that matches the original files into an in-memory format optimized for graphics output. It does this in order to improve run-time rendering performance, and if "Memory Usage" is set to "High", it sort of inlines the final geometry, but LDView's file loading code definitely doesn't inline.


Re: coding a quick inline process in .NET (visual basic) - Michael Heidemann - 2014-06-27

Thanks Travis. That's a good point. I'll try to implement a 'list of referenced files'. This should really speed up parts inlining if many primitives and subfiles are used.

Let me just explain a little bit how I organized things.
1) an ldr/dat file is an object that has head data like author, description etc. and lines.
2) the lines are stored in a System.Collections.Generic.List(Of cls_LDraw_Line)
3) each line is an object of type cls_LDraw_Line
4) each object of type cls_LDraw_line consists of the known x,y,z,a,b......, reference, linetype, linecolor, metacommand

This design is very comfortable for coding, but maybe not that useful for speedy applications.


Re: coding a quick inline process in .NET (visual basic) - Roland Melkert - 2014-06-28

I was thinking about a whole different kind of inlineing Smile

I'm doing basically the same with LDCad as Travis described for LDView. But I don't keep reference counts as it never unloads LDraw data at the moment (part of the undo system).

It's a fairly simple/efficient system, only hard thing to get going is making it all multi threaded.


Re: coding a quick inline process in .NET (visual basic) - Michael Heidemann - 2014-06-28

Thanks again for your feedback. I thought that you were talking about a different inlining Smile As far as I know c or c++ is able to inline code, but that is not what I am looking for.

It seems that my approach is somewhat procedure coded so I do not have multi tasking coded at present.

I read the file
I parse the file (into an object)
The lines of this object are then inlined.
If it is a linetype 1 then I read the reference file from disk (see above.....)

But I think this reading is not the time consuming factor, as is does not really read from the disk (content is still in memory). I guess.

So it must be something wrong with my objects.