Re: [TCLCORE] [flightaware/Tcl-bounties] Intent to work on speedups to `clock format` and `clock scan` (#4)

 

No time currently to answer detailed, so firstly I'll try to summarize
as short answer... 

1) Yes

2) All the test-cases modifications, that I done, going to bug-fixing
(IMHO) and to cover new functionality (like "-now" by "clock format -now
-format ..."). 

3) Yes (otherwise several test-cases will fail) 

4) There was also in scope (no chances to get reasonable
performance-increase without optimization of msgcat-clock binding).

5) Yes. It is only my own code (licensed as TCL self). 

6) Yes, almost nothing uncovered (only pair code blocks serves debugging
purposes). 

As regards of ensemble compilation for [clock], I've seen it (you've
made it for commands like seconds, microseconds, etc.), but I've another
branch, where ALL ensembles will be compiled (using rewritten much
faster version of INST_INVOKE_REPLACE), see
https://github.com/flightaware/Tcl-bounties/issues/21#issuecomment-270655556.
I'll try to rebase it into fossil. 

Regards,
sebres 

08.04.2017 04:46, Kevin Kenny wrote: 

> Copying tcl-core on this as well:> > On 04/07/2017 02:25 PM, Serg G. Brester wrote:> >> Thanks for the reminder (just too many tasks)! Nop, I think, we don't need a TIP as long as it is not realy an enhancement (besides the little incompatibilities, which belong rather to bug fixing resp. some artifical cases). I hoped for some feadback from TCT (or/and from flightaware;), but excepting pair colleagues I got nothing up to now from there. Inbetween I had found a small "bug" there, that is already fixed (must be rebased in fossil). And I've tested it on some systems of me using tcl (where it looks very good all the time). So I'll try to make a back-porting to 8.6 the next week (should be relative easy, because I almost alone dare to change there something;), and then to start CFV survey for ca. two weeks for both 8.6 and trunk branches (I hope one or the other is accepted, or I'm listening some agruments against, that I can then "fix"). -- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub
<https://github.com/flightaware/Tcl-bounties/issues/4#issuecomment-292614764 [1]>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANPUYJBdJqeY1VEu2mWggcT8p49fvzrks5rtn-PgaJpZM4K2cWi [2]>.
> > I don't recall ever getting answers to several questions that I asked. > It could be that there were technological issues that kept us from > making contact.> > (1) Are you willing to maintain the code moving forward? (If not, I need > more time to review. Things have been very busy for the last few months, > and I've not had time to source-dive in your separate branches.> > (2) What, if any, existing test cases needed to be modified to support > your performance improvements, and why? (If they were there simply for > 'bugward compatibility', that's an acceptable answer. I recognize that > some of the Tcl test cases have historically not been tests, but rather > experiments.> > (3) Does the code continue to support multilocalization (having places > in the same process or in the same interpreter where different time > zones or locales are in use)?> > (4) Is the claimed speedup achievable without also addressing the msgcat > subsystem, or were speedups there also in scope?> > (5) Is the new code still self-contained, or does it rely on third-party > libraries that are subject to licensing that must be reviewed?> > (6) Has the new code been run with the test suite under a profiler such > as gcov (or nagelfar for any portions that are still written in Tcl)? > What fraction of the code remains uncovered?> > If all of these questions have acceptable answers, then I don't think > there's any need for a vote. I speak both as a TCTer and as the > maintainer of record for [clock]. We just need to get you commit access > for (1) - I can do that if you agree - and then get everything merged > in. I presume documentation changes should be minimal, just the new %Es > plus documenting any other new functionality needed. If it's a drop-in > replacement that passes the test suite, I don't have a problem with it > appearing in a point release.> > If you haven't merged recently, you'll also find that I added ensemble > compilation for [clock] (and for [encoding] which was also missing it). > In addition, I added bytecoding for [clock > seconds/millis/micros/clicks], which should be an additional little > boost. I just dropped those into core-8-6-branch as well as trunk, and > nobody objected.> > Thanks for taking this on! I'd been meaning to do the rewrite in C > (which for me would have been relatively straightforward but > time-consuming) for years, but always had other fish to fry. Doing the > initial implementation in C would have got me horribly bogged down, so I > still think that proving the concept in Tcl first was a good idea, but > somehow, the Tcl implementation always remained Almost Good Enough and > the performance hacking never got enough attention.
 

Links:
------
[1]
https://github.com/flightaware/Tcl-bounties/issues/4#issuecomment-292614764
[2]
https://github.com/notifications/unsubscribe-auth/AANPUYJBdJqeY1VEu2mWggcT8p49fvzrks5rtn-PgaJpZM4K2cWi

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot