D Burgess, on Wednesday, January 1, 2020 08:19 PM, wrote...
>
> > I’ve spent too much time lately trying to figure out or debug
> hellacious C spaghetti code
>
> And I’ve spent too much time lately trying to figure out or debug
> hellacious C++ spaghetti code
>
> Someone who writes bad C, will
Also spaghetti inheritance is a thing.
On Wed, Jan 1, 2020, 19:19 D Burgess wrote:
> > I’ve spent too much time lately trying to figure out or debug hellacious
> C spaghetti code
>
> And I’ve spent too much time lately trying to figure out or debug
> hellacious C++ spaghetti code
>
> Someone
> I’ve spent too much time lately trying to figure out or debug hellacious C
> spaghetti code
And I’ve spent too much time lately trying to figure out or debug
hellacious C++ spaghetti code
Someone who writes bad C, will write even worse C++
___
> On Dec 31, 2019, at 7:03 AM, Richard Damon wrote:
>
> 1) The C API between separate compilations is very well established, and
> fully documented in most environments.
Agreed. APIs between library boundaries generally need to be C. This is pretty
easy to do though (I've done it multiple
On 31 Dec 2019, at 3:03pm, Richard Damon wrote:
> I will give a short answer, in my opinion, of a few reasons on why C is still
> a viable language.
5) SQLite has to work on your set top box. On your Wifi base station. On your
Home hub. On the machine that runs the car park. All these
On 12/31/19 3:13 AM, Jens Alfke wrote:
On Dec 30, 2019, at 6:23 PM, Alexander Vega wrote:
-fdevirtualize
-fdevirtualize-speculatively
I believe those are C++ optimizations, specific to C++ virtual methods. What
SQLite is doing is similar to a class with virtual methods, but done “by hand”
> On Dec 30, 2019, at 6:23 PM, Alexander Vega wrote:
>
> -fdevirtualize
> -fdevirtualize-speculatively
I believe those are C++ optimizations, specific to C++ virtual methods. What
SQLite is doing is similar to a class with virtual methods, but done “by hand”
in plain C, so the optimizer
On 31 Dec 2019, at 2:21am, Alexander Vega wrote:
> Could there be some compile time option to force Linux or Windows
> statically?
One of the problems with this is that there are a lot of utility libraries
built around SQLite. These are libraries provided for general-purpose use,
often a
I watched the video and wondered about the virtual table calls within
sqlite as well. Without them you would have no VFS though... so they are
needed. Could there be some compile time option to force Linux or Windows
statically? Maybe.
I do not know the effect of collecting debug information
> On Dec 30, 2019, at 7:19 AM, Doug wrote:
>
> I am suggesting that if the we added the global calls to the underlying
> functions to the API - that is, the functions that are called by the function
> table indirection - then one could code the application to call the
> underlying
On 12/30/19 10:19 AM, Doug wrote:
OK, I get that the definition of the SQLite API is a (large) set of C function
calls. And that changing the way they work under the covers would break
something. (Check out the IDEA below!)
I'm wondering if your use case is - in the same application - that
On Wed, Dec 25, 2019 at 4:25 PM Richard Hipp wrote:
>
> The video provided details on what they did. I could not find any
> performance improvement by making mutexes direct calls instead of
> indirect calls.
This kind of optimization improves performance by reducing pressure on the
CPU's
bject: Re: [sqlite] Causal profiling
>
>
>
> > On Dec 26, 2019, at 3:45 PM, Doug wrote:
> >
> > Can you explain what the API is that you use to "set concurrency
> levels per connection", please? Is it a parameter on open() or its
> own function ca
> On Dec 26, 2019, at 3:45 PM, Doug wrote:
>
> Can you explain what the API is that you use to "set concurrency levels per
> connection", please? Is it a parameter on open() or its own function call?
> And how would the API break, exactly?
sqlite3_config(), specifically the
On Fri, 27 Dec 2019 at 06:11, Jens Alfke wrote:
>
> > On Dec 25, 2019, at 2:53 PM, Doug wrote:
> >
> > I wrote an application in Qt which uses SQLite. Therefore, I invoke
> SQLite functions with some wrapper. For a 9% performance improvement in
> SQLite using the direct call versus indirect
> -Original Message-
> From: sqlite-users
> On Behalf Of Jens Alfke
> Sent: Thursday, December 26, 2019 3:11 PM
> To: SQLite mailing list
> Subject: Re: [sqlite] Causal profiling
>
>
>
> > On Dec 25, 2019, at 2:53 PM, Doug wrote:
> >
> > I
> On Dec 25, 2019, at 2:53 PM, Doug wrote:
>
> I wrote an application in Qt which uses SQLite. Therefore, I invoke SQLite
> functions with some wrapper. For a 9% performance improvement in SQLite using
> the direct call versus indirect call (as discussed in the talk), cannot the
> wrapper
On 12/25/19, Doug wrote:
> Richard, can you please explain each of these?
>
> 1. API break
> I wrote an application in Qt which uses SQLite. Therefore, I invoke SQLite
> functions with some wrapper. For a 9% performance improvement in SQLite
> using the direct call versus indirect call (as
at the talk again re performance measurements), what did you use to
measure the results?
Best, Doug
> -Original Message-
> From: sqlite-users
> On Behalf Of Richard Hipp
> Sent: Wednesday, December 25, 2019 3:18 PM
> To: SQLite mailing list
> Subject: Re: [sqlite
On 12/25/19, sky5w...@gmail.com wrote:
> Thanks for sharing!
> Did his suggested optimization make it to a commit?
No. That would be an API break, and would also render SQLite
untestable. Furthermore, we have been unable to replicate the
performance gains.
--
D. Richard Hipp
d...@sqlite.org
Thanks for sharing!
Did his suggested optimization make it to a commit?
On Wed, Dec 25, 2019 at 10:46 AM Craig H Maynard wrote:
> All,
>
> Just watched an interesting lecture by UMass professor Emery Berger on
> improving software performance:
>
> https://www.youtube.com/watch?v=r-TLSBdHe1A
>
>
All,
Just watched an interesting lecture by UMass professor Emery Berger on
improving software performance:
https://www.youtube.com/watch?v=r-TLSBdHe1A
SQLite is discussed in the section on causal profiling, which begins at 34:12.
Craig
--
Craig H Maynard
Rhode Island, USA
401.413.2376
22 matches
Mail list logo
