Generate QListBox and without Objects. Arrays are much faster.

Yeah, it's definitely a valid point.  But again, the main issue is -- how do we know which property to use as the “display” of each listitem?  Or, better yet, with your example, what if you want the “display” of each listitem to be a concatenation of multiple fields in the object or some other calculated value?

Mike, if I'm not wrong, Tronics is not talking about active records here, but about a kind of QListBox control that work without QListItem objects.

Tronics, I really see a curious background conflict in choosing a fully OO framework and then tend to avoid using objects everywhere you make an intensive use of them. I find it justified when talking about query results, that tend to be massively instantiated, but there must be a compromise that doesn't break the framework philosophy.

About this case, in my opinion, a listbox that contains tenths of items might be substituted with a different control just for its bad HTML usability. Maybe an autocompletion textbox or a modal lightbox with a paginated selection datagrid would suit the need.

I don't understand when you say that the toString() method is obsolete for the model. In your example you can bypass the second parameter entirely just relying on it, if you're not displaying special calculations.

By the way, caching precompiled code (with APC) helps a lot in my case, from 30% to 90% gains in memory, depending on the nature of the request calculations. Anyway I usually don't do websites, but web applications with a very intensive use of a lot of classes, so I don't know if this will help you.

Hello Fernando, thank you for your inputs.

Please let me clarify..(I edited this posting to make it more to the point)

With this thread I just want to suggest to create one additional QForm element  QListBoxArray that is very performant by using Arrays.

This QForm would then be a great usecase of a performant implementation using arrays and could easily be adjusted for different additional uses (eg by combining with some JQuery plugins that also just need very fast some array values in JSON Format or something..... Example are JS datagrids or trees).

So the usefulness is not only about a QListbox replacement here..
Rather having a best practice way to make performant QForm Controls and there a QListBox really is often needed.

Mike has already made a fantastic tool with the autocompleteTextbox which is very useful for larger count entries. Thanks for that it is great.

However tackling directly the QListBox would also be awesome.

Other ORMs like Doctrine and Propel offer this possibility and they are widely used. The performance difference is of course depending on your application but benchmarks in these ORMs showed amazing 'up to 60 times faster' improvements.

Here is also a relatively concrete Example:

If you have:
- 10 Listboxes
- with each 40 entries on one form
-> I generate 400 Objects from the model
-> and also additional Qquery and Qform objects etc..

...at least xxxx Objectinstances are flowing around in the memory.
But we are still only talking about 10 Listboxes, that is not like a bloated UI or something.
Yet some of these Listboxes might come from different very populated tables in terms of many columns (Person 70 Columns, Item 80 Columns, etc.) with foreignkeys and that makes the whole thing more costly.

The option to cut down a few of these by using arrays would really cut down a lot of performance cost.
That same example with datagrid is probably even worse on the clientside because of all the UI elements, additional clicks and large JS footprint in the HTML delivered.

--

Hope this makes a little clear where I'm coming from.
Regarding the QListBoxArray - It would not blow up the framework nor make anything obsolete we have achieved - just a nice performant addition that is supported right out of the box (and therefore no individual hacking required for people wanting to use arrays)

Regards,
tronics

Sorry for coming back so late.
Somehow I overlooked the topic that is so important for me.

Memory footprint is a huge problem of all ORMs.
Basically I do believe that the reason why Qcodo is in some respects not 'very fast' lies in the high quality of abstration, say too many objects.

Other frameworks have the same problem:
http://stackoverflow.com/questions/1412762/doctrine-query-memory-usage

But they provide mechanisms relying on arrays instead of objects to conquer that:
http://www.doctrine-project.org/documentation/manual/1_1/0_10/improving-performance:conservative-fetching

Basically I believe having the option to retrieve only the data needed as array to build the dropdown (or other qform) via the ORM would be great.

Like the principle of conservative fetching in doctrine.
The important thing is having a shortcut that is still matching our way of doing things (so it is not a hack) but much less generation of objects.

Ok, I will try to find a concrete testcase where we can see an advantage and eventually a solution. If I find something usefull I will need your expertise on the OO design.
Btw. I have integrated a different ORM (featuring this array approach) just for fun. But I could not benchmark it together with QForm so far.
That would probably be an interesting first step as there are a lot of objects generated starting with ->LoadAll() and ending at QListBoxItem. Most probably more of these for the ORM then for the QListBox.

Cheers,
tronics