3 Replies Latest reply on Feb 18, 2008 4:53 PM by pmuir

    Seam binding performance

    tom_goring

      Hi,


      I have a backing bean like:



      @Name(“messageBoard”)
      Public class MessageBoard {
      ..
      Public List<MessageThread> getThreadList() {
      …
      }
      }
      





      And a Facelet like:



      <c:forEach items=#{messageBoard.threadList} var=”row”>
      …
      



      N.b. I’m using c:forEach due to ajax requirements I have within the repeated area.  Also getThreadList is quick (i.e. not the problem).


      During render response it takes ages due to loads of Seam events firing (even for 20 rows taking 10sec).  I think this is due to bi-injection occurring lots of times during the facelet render phase.  If I change the loop to iterate like follows things speed up quite a bit:


      @Factory(“messgeBoardList”)
      Public List<MessageThread> getThreadList() {
      …
      }
      


      <c:forEach items=#{messageBoardList} var=”row”>
      …
      



      Any advise or explanation would be helpful.


        • 1. Re: Seam binding performance
          gavin.king

          If I were you I would try to avoid c:forEach. Try ui:repeat instead.

          • 2. Re: Seam binding performance
            tom_goring

            Hi, yes i understand that c:forEach will create a component tree on the server side with items for each row in the repeat section.  I need this so that I can do some richFaces ajax stuff to dynamically drill into the repeat area.  This all works fine it's just performance is very poor during the render response phase.


            It looks to me loads of Seam events are firing every time during the render response phase my backing bean is accessed. 


            My requirment is to show a list of items and allow the user to open up one of those items (via ajax) to show sub items.


            Thanks in advance

            • 3. Re: Seam binding performance
              pmuir

              c:forEach is very slow - don't use it. Seam events are not the problem here!