Hi Steven,
Thank you for picking up that task!
> I'd prefer #define'd strings, simply because the compiler can optimize
this easily. If the compiler can optimize "const char *" just as well,
let's do that instead.
It depends on the kind of optimization. In some rar cases #defines are
better optimized for runtime but I would prefer const char *, because a
better IDE support.
If we also use % instead of + for string connection it should be fine from
performance view.
Kind regards,
Daniel
2013/5/2 Steven Boswell II <[email protected]>
> On Wednesday, May 1, 2013 at 11:42 AM, RJ Ryan wrote:
>
> >On Wed, May 1, 2013 at 2:15 PM, Daniel Schürmann wrote:
> >>Yes, we should solve this issue and use the const values in any case.
> >>This allows to rely on IDE features like "display call tree".
> >
> >I think we should stick with whatever makes the code easiest to
> >maintain (which would be using the constants when possible) -- maybe
> >the constants should be renamed to be a little easier on the eyes? A
> >lot of the DAO code doesn't use the constants, that's true. We should
> >fix those queries.
>
> Oy...OK. I'll keep the source-code comment with the human-readable
> version, just to make it easier to understand.
>
>
> >>But I am not sure if the use of const QString is performance neutral
> >>to const char* and #define because the heavy QSting constructor is
> >>called.
> >>
> >>So IMHO we should change it to const char*.
>
> From what I've seen, the table names are #define'd strings, and the column
> names are global QString objects. Seems like we should have one way to do
> this. I'd prefer #define'd strings, simply because the compiler can
> optimize this easily. If the compiler can optimize "const char *" just as
> well, let's do that instead.
>
> I try to make sure my code runs well on low-end hardware (a side effect of
> programming video-game consoles for so many years... :-)
>
>
> >There are a lot of non-performance-neutral choices we make in Mixxx,
> >but that alone isn't enough to make a decision, we have to take the
> >context into account. Compared to the QSqlQuery::exec() that comes
> >immediately after all these queries, some string concatenation isn't
> >going to break the bank, cycle-wise. Processors are pretty good at
> >memcpy these days :).
>
> That's fine until we try to run Mixxx on a GP2X. :-)
>
>
> On Wednesday, May 1, 2013 at 12:07 PM, RJ Ryan wrote:
> >I would prefer we totally got rid of writing SQL queries directly in
> >code and instead composed them using declarative C++ classes which are
> >then compiled down to SQL.
>
> That's one thing I really like about C# 3.0 ... the introduction of LINQ.
> So much programming revolves around database queries; it's hard to believe
> that it's taken this long for database-queries to become a first-class
> member of the language, or that only one language has figured this out so
> far.
>
> Steven Boswell
>
>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
> http://mixxx.org
>
>
> Mixxx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
