| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 4 | |
Hello everyone. Isn't it time for Qt (the best library out there), to have garbage collection? Boehm's gc is mature software and it exists for all major platforms. Qt's memory management pattern (ownership of objects) is not enough when objects are used in complex ways. Furthermore, lots of Qt classes do not inherit from QObject, making them difficult to be used with manual memory management. Reference counting is not the appropriate solution for memory management, because a) it does not handle cycles (and Qt objects have quite a lot of thme), b) it hurts performance. -- [ signature omitted ]
Achilleas Margaritis wrote: >Hello everyone. > >Isn't it time for Qt (the best library out there), to have garbage >collection? Boehm's gc is mature software and it exists for all major >platforms. > >Qt's memory management pattern (ownership of objects) is not enough when > objects are used in complex ways. Furthermore, lots of Qt classes do >not inherit from QObject, making them difficult to be used with manual >memory management. > >Reference counting is not the appropriate solution for memory >management, because a) it does not handle cycles (and Qt objects have >quite a lot of thme), b) it hurts performance. Sorry to be so harsh, but this is definitely a no-go for Qt 4.x. We cannot just change the way the library works in the same major series. So we can revisit this issue when Qt 5.0 is being developed -- which shouldn't happen for the next 3-5 years at least. And even then, only if we find strong reason to support it. I also find it strange that you say that reference counting hurts performance, while GC wouldn't. Most people I know complain about Java VM's garbage collector's impact on their application's performance. Did you take that into account? Wouldn't a simple solution of a smart pointer class help you for automating some of the memory management? I have such class already written for Qt, but it didn't make to Qt 4.4. It's a thread-safe, polymorphic-capable implementation of smart pointers including weak-references. Unfortunately, it requires an object of 2*sizeof(void*) for each reference, plus a 12- or 16-byte object shared between all instances. I don't know if that's acceptable performance. Now, some parts of Qt do use garbage collecting. QtScript is the most common case, because it is required by the ECMA specification, the pixmap cache is another (it's a cache). I don't doubt that other areas can use that too. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
On 24.12.07 13:20:25, Achilleas Margaritis wrote: > Isn't it time for Qt (the best library out there), to have garbage > collection? Boehm's gc is mature software and it exists for all major > platforms. AFAIK that has been discussed extensively a longer while ago (last year or so), dunno the outcome though. > Furthermore, lots of Qt classes do not inherit from QObject, making > them difficult to be used with manual memory management. Most of those are usually used in non-pointer ways, i.e. allocating them on the stack and using their copy-operations. > Reference counting is not the appropriate solution for memory > management, because a) it does not handle cycles (and Qt objects have > quite a lot of thme), b) it hurts performance. Have you actually read how ref-counting and implicit sharing is implemented in Qt4? Sure there's been a slight overhead compared to non-ref-counting, but I guess a garbage collector has a similar overhead. Andreas -- [ signature omitted ]
Achilleas Margaritis wrote: > Hello everyone. > > Isn't it time for Qt (the best library out there), to have garbage > collection? Boehm's gc is mature software and it exists for all major > platforms. > > Qt's memory management pattern (ownership of objects) is not enough when > objects are used in complex ways. Furthermore, lots of Qt classes do > not inherit from QObject, making them difficult to be used with manual > memory management. > > Reference counting is not the appropriate solution for memory > management, because a) it does not handle cycles (and Qt objects have > quite a lot of thme), b) it hurts performance. You seem to buying into a lot of myths about reference counting. Have you collected much data that shows that Qt's memory management is adversely affecting your application performance? I've been using reference-counting in my own commercial applications for over a decade - some of them real-time graphics applications, and never felt that reference-counting was impairing performance. And with some careful design, a cyclic reference pattern has NEVER come up. -- [ signature omitted ]
Reference counted pointers take up a few dozen cycles to execute their operations, where as raw pointers take a few cycles. But aside from that (in this day and age, performance is not the main problem), what about programmer performance? I am about to write a big application, the contractor insists on using C++, the deadline is 3 months, and the penalties for delay are severe. What choices do I have? reference counting will only solve some problems, but I can't do it without thinking about memory management...and having to think about memory management will add at least 30% development time. Qt is so nice...if only it had garbage collection! O/H Paul Miller έγραψε: > Achilleas Margaritis wrote: >> Hello everyone. >> >> Isn't it time for Qt (the best library out there), to have garbage >> collection? Boehm's gc is mature software and it exists for all major >> platforms. >> >> Qt's memory management pattern (ownership of objects) is not enough when >> objects are used in complex ways. Furthermore, lots of Qt classes do >> not inherit from QObject, making them difficult to be used with manual >> memory management. >> >> Reference counting is not the appropriate solution for memory >> management, because a) it does not handle cycles (and Qt objects have >> quite a lot of thme), b) it hurts performance. > > You seem to buying into a lot of myths about reference counting. Have > you collected much data that shows that Qt's memory management is > adversely affecting your application performance? > > I've been using reference-counting in my own commercial applications for > over a decade - some of them real-time graphics applications, and never > felt that reference-counting was impairing performance. And with some > careful design, a cyclic reference pattern has NEVER come up. > -- [ signature omitted ]
Achilleas Margaritis wrote: > Reference counted pointers take up a few dozen cycles to execute their > operations, where as raw pointers take a few cycles. Good ones have one extra pointer indirection - same as a virtual function call. > But aside from that (in this day and age, performance is not the main > problem), what about programmer performance? > > I am about to write a big application, the contractor insists on using > C++, the deadline is 3 months, and the penalties for delay are severe. > > What choices do I have? reference counting will only solve some > problems, but I can't do it without thinking about memory > management...and having to think about memory management will add at > least 30% development time. You mention programmer performance. I use boost intrusive reference-counted pointers for most items in my object models, and almost never "think" about memory management. Maybe, since I've been doing this for so long, I'm just used to it. And, I can actually "know" when my memory is getting cleaned up, which is useful in high-performance graphics software. I just think you're undervaluing reference-counting. The "problems" with them are very few (or non-existent) to me. > > Qt is so nice...if only it had garbage collection! > > > O/H Paul Miller έγραψε: >> Achilleas Margaritis wrote: >>> Hello everyone. >>> >>> Isn't it time for Qt (the best library out there), to have garbage >>> collection? Boehm's gc is mature software and it exists for all major >>> platforms. >>> >>> Qt's memory management pattern (ownership of objects) is not enough when >>> objects are used in complex ways. Furthermore, lots of Qt classes do >>> not inherit from QObject, making them difficult to be used with manual >>> memory management. >>> >>> Reference counting is not the appropriate solution for memory >>> management, because a) it does not handle cycles (and Qt objects have >>> quite a lot of thme), b) it hurts performance. >> >> You seem to buying into a lot of myths about reference counting. Have >> you collected much data that shows that Qt's memory management is >> adversely affecting your application performance? >> >> I've been using reference-counting in my own commercial applications >> for over a decade - some of them real-time graphics applications, and >> never felt that reference-counting was impairing performance. And with >> some careful design, a cyclic reference pattern has NEVER come up. >> > > -- > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with > "unsubscribe" in the subject or the body. > List archive and information: http://lists.trolltech.com/qt-interest/ > > -- [ signature omitted ]
O/H Paul Miller έγραψε: > Achilleas Margaritis wrote: >> Reference counted pointers take up a few dozen cycles to execute their >> operations, where as raw pointers take a few cycles. > > Good ones have one extra pointer indirection - same as a virtual > function call. > >> But aside from that (in this day and age, performance is not the main >> problem), what about programmer performance? >> >> I am about to write a big application, the contractor insists on using >> C++, the deadline is 3 months, and the penalties for delay are severe. >> >> What choices do I have? reference counting will only solve some >> problems, but I can't do it without thinking about memory >> management...and having to think about memory management will add at >> least 30% development time. > > You mention programmer performance. I use boost intrusive > reference-counted pointers for most items in my object models, and > almost never "think" about memory management. Maybe, since I've been > doing this for so long, I'm just used to it. And, I can actually "know" > when my memory is getting cleaned up, which is useful in > high-performance graphics software. > > I just think you're undervaluing reference-counting. The "problems" with > them are very few (or non-existent) to me. > >> >> Qt is so nice...if only it had garbage collection! >> >> >> O/H Paul Miller έγραψε: >>> Achilleas Margaritis wrote: >>>> Hello everyone. >>>> >>>> Isn't it time for Qt (the best library out there), to have garbage >>>> collection? Boehm's gc is mature software and it exists for all major >>>> platforms. >>>> >>>> Qt's memory management pattern (ownership of objects) is not enough >>>> when >>>> objects are used in complex ways. Furthermore, lots of Qt classes do >>>> not inherit from QObject, making them difficult to be used with manual >>>> memory management. >>>> >>>> Reference counting is not the appropriate solution for memory >>>> management, because a) it does not handle cycles (and Qt objects have >>>> quite a lot of thme), b) it hurts performance. >>> >>> You seem to buying into a lot of myths about reference counting. Have >>> you collected much data that shows that Qt's memory management is >>> adversely affecting your application performance? >>> >>> I've been using reference-counting in my own commercial applications >>> for over a decade - some of them real-time graphics applications, and >>> never felt that reference-counting was impairing performance. And >>> with some careful design, a cyclic reference pattern has NEVER come up. >>> >> >> -- >> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with >> "unsubscribe" in the subject or the body. >> List archive and information: http://lists.trolltech.com/qt-interest/ >> >> > > Perhaps for your needs, reference counting works. Not for me. My requirements include very complex object models with cycles introduced via interfaces. -- [ signature omitted ]
I've just managed to compile Qt with Boehm's gc. It's perfect. I run all the demos, and there was no problem. No more memory leaks for me, no need to worry about cycles, no need to use other languages than c++ and Qt. Happy new year to everyone! O/H Paul Miller έγραψε: > Achilleas Margaritis wrote: >> Reference counted pointers take up a few dozen cycles to execute their >> operations, where as raw pointers take a few cycles. > > Good ones have one extra pointer indirection - same as a virtual > function call. > >> But aside from that (in this day and age, performance is not the main >> problem), what about programmer performance? >> >> I am about to write a big application, the contractor insists on using >> C++, the deadline is 3 months, and the penalties for delay are severe. >> >> What choices do I have? reference counting will only solve some >> problems, but I can't do it without thinking about memory >> management...and having to think about memory management will add at >> least 30% development time. > > You mention programmer performance. I use boost intrusive > reference-counted pointers for most items in my object models, and > almost never "think" about memory management. Maybe, since I've been > doing this for so long, I'm just used to it. And, I can actually "know" > when my memory is getting cleaned up, which is useful in > high-performance graphics software. > > I just think you're undervaluing reference-counting. The "problems" with > them are very few (or non-existent) to me. > >> >> Qt is so nice...if only it had garbage collection! >> >> >> O/H Paul Miller έγραψε: >>> Achilleas Margaritis wrote: >>>> Hello everyone. >>>> >>>> Isn't it time for Qt (the best library out there), to have garbage >>>> collection? Boehm's gc is mature software and it exists for all major >>>> platforms. >>>> >>>> Qt's memory management pattern (ownership of objects) is not enough >>>> when >>>> objects are used in complex ways. Furthermore, lots of Qt classes do >>>> not inherit from QObject, making them difficult to be used with manual >>>> memory management. >>>> >>>> Reference counting is not the appropriate solution for memory >>>> management, because a) it does not handle cycles (and Qt objects have >>>> quite a lot of thme), b) it hurts performance. >>> >>> You seem to buying into a lot of myths about reference counting. Have >>> you collected much data that shows that Qt's memory management is >>> adversely affecting your application performance? >>> >>> I've been using reference-counting in my own commercial applications >>> for over a decade - some of them real-time graphics applications, and >>> never felt that reference-counting was impairing performance. And >>> with some careful design, a cyclic reference pattern has NEVER come up. >>> >> >> -- >> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with >> "unsubscribe" in the subject or the body. >> List archive and information: http://lists.trolltech.com/qt-interest/ >> >> > > -- [ signature omitted ]