This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> Er, why not start by defining a relevant interface and then work > inwards? That way potential clients, such as paulh, can determine if it > is sufficient for their needs. The first implementation doesn't even > need to be fast, just correct. Once we've hard data on the interfaces > run-time behavioral characteristics we can consider symtab internal
> changes.
Because the cleaner interface is not my goal - it's a side goal to my actual aims, which are improved GDB startup time and memory usage. An implementation which is not fast is a step backwards. I don't understand how you can propose to measure "hard data" on "run-time behavioral characteristics" without implementing the symtab internal changes - what am I missing?
- how often it is called? - when it is called? - with what parameters it is called? - how time critical are the calls?
The symbol table is already a mess, with multiple redundant interfaces. At the moment there isn't a clear picture of what various bits of gdb need from the symbol table. How do we know the direction we are going is improving things generally across the board? How can we know that, if this is not the case, the impact is not too heavy on other parts and we can live with the tradeoff?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |