ฉันจะสำรวจต้นไม้โดยไม่ใช้การเรียกซ้ำได้อย่างไร

ฉันมีขนาดใหญ่มากในทรีโหนดหน่วยความจำและจำเป็นต้องสำรวจทรี การส่งค่าที่ส่งคืนของโหนดชายด์แต่ละโหนดไปยังโหนดพาเรนต์ สิ่งนี้จะต้องทำจนกว่าโหนดทั้งหมดจะมีบับเบิลข้อมูลจนถึงรูตโหนด

การสำรวจเส้นทางทำงานเช่นนี้

private Data Execute(Node pNode)
{
    Data[] values = new Data[pNode.Children.Count];
    for(int i=0; i < pNode.Children.Count; i++)
    {
        values[i] = Execute(pNode.Children[i]);  // recursive
    }
    return pNode.Process(values);
}

public void Start(Node pRoot)
{
    Data result = Execute(pRoot);
}

ใช้งานได้ดี แต่ฉันกังวลว่า call call จะ จำกัด ขนาดของทรีโหนด

วิธีการสามารถรหัสถูกเขียนใหม่เพื่อให้ไม่มีการโทร recursive จะExecuteทำ?

นี่คือการใช้การสำรวจเส้นทางแบบทรีเพื่อวัตถุประสงค์ทั่วไปที่ไม่ใช้การเรียกซ้ำ

public static IEnumerable<T> Traverse<T>(T item, Func<T, IEnumerable<T>> childSelector)
{
    var stack = new Stack<T>();
    stack.Push(item);
    while (stack.Any())
    {
        var next = stack.Pop();
        yield return next;
        foreach (var child in childSelector(next))
            stack.Push(child);
    }
}

ในกรณีของคุณคุณสามารถเรียกได้ว่า:

IEnumerable<Node> allNodes = Traverse(pRoot, node => node.Children);

ใช้การQueueค้นหาStackแบบกลมๆก่อนแทนที่จะค้นหาความลึกก่อน ใช้PriorityQueueสำหรับการค้นหาครั้งแรกที่ดีที่สุด

หากคุณมีการประเมินความลึกของต้นไม้ของคุณไว้ล่วงหน้าอาจเป็นเรื่องที่เพียงพอสำหรับกรณีของคุณในการปรับขนาดสแต็ค ใน C # ตั้งแต่รุ่น 2.0 สิ่งนี้เป็นไปได้ทุกครั้งที่คุณเริ่มหัวข้อใหม่ดูที่นี่:

http://www.atalasoft.com/cs/blogs/rickm/archive/2008/04/22/increasing-the-size-of-your-stack-net-memory-management-part-3.aspx

ด้วยวิธีนี้คุณสามารถเก็บรหัสซ้ำโดยไม่ต้องใช้อะไรที่ซับซ้อนกว่านี้ แน่นอนว่าการสร้างโซลูชันที่ไม่ใช่แบบเรียกซ้ำด้วยสแต็กของคุณเองอาจมีเวลามากขึ้นและมีประสิทธิภาพของหน่วยความจำ แต่ฉันค่อนข้างมั่นใจว่ารหัสจะไม่ง่ายอย่างที่เป็นอยู่ในตอนนี้

คุณไม่สามารถข้ามโครงสร้างข้อมูลในรูปของทรีโดยไม่ต้องใช้การเรียกซ้ำ - ถ้าคุณไม่ใช้สแต็กเฟรมและการเรียกใช้ฟังก์ชันที่ภาษาของคุณให้คุณต้องตั้งโปรแกรมสแต็กและฟังก์ชั่นการโทรของคุณเอง ไม่น่าที่คุณจัดการที่จะทำมันภายในภาษาในวิธีที่มีประสิทธิภาพมากขึ้นกว่าที่นักเขียนคอมไพเลอร์ได้ในเครื่องที่โปรแกรมของคุณจะทำงานบน

ดังนั้นการหลีกเลี่ยงการเรียกซ้ำเนื่องจากกลัวว่าจะเกิดข้อ จำกัด ด้านทรัพยากรจึงมักจะเข้าใจผิด เพื่อให้แน่ใจว่าการเพิ่มประสิทธิภาพทรัพยากรก่อนวัยอันควรเข้าใจผิดเสมอแต่ในกรณีนี้มีความเป็นไปได้ที่แม้ว่าคุณจะวัดและยืนยันว่าการใช้หน่วยความจำเป็นคอขวดคุณอาจจะไม่สามารถปรับปรุงได้โดยไม่ต้องลดลงไปถึงระดับ นักเขียนคอมไพเลอร์